TSN-Serie Teil 17
Erste Schritte in die Praxis
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.
Die Konfiguration des Switches
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.
Konfiguration des Publishers/Talkers in Automation Studio
Zum Erstellen der Pub/Sub-Konfiguration für die B&R-Steuerungen in Automation Studio, ist nach dem Erstellen der Hardware-Konfiguration, unter dem Punkt „Connectivity“ eine OPC-UA-Konfiguration einzufügen, in der nur Variablen, die für die Benutzung durch OPC-UA aktiviert sind, genutzt werden können. Alle wichtigen Einstellungen, wie zum Beispiel die Multicast-Adresse der Pakete, die Publisher-ID sowie das Übertragungsintervall werden dort festgelegt und das Published-Dataset einer ‚Writer-Group‘ erzeugt, in dem angegeben wird, welche Variablen, an welcher Stelle in den DataSet-Messages des OPC-UA-Pub/Sub-Systems enthalten sind. Zur einfachen Konfiguration der Subscriber lässt sich diese Konfiguration dann durch Rechtsklick auf die Publisher-Konfiguration als ‚.uabinary‘-Datei exportieren und bei den Subscribern wieder einlesen, so dass diese die übertragenen Binärdaten richtig interpretieren können. Die Einstellungen für die TSN-Funktionalität des Pub/Sub-Systems müssen auf der Konfigurations-Seite explizit eingeblendet werden (grüner Knopf in der oberen Leiste des Editors), um die VLAN-Konfiguration bearbeiten zu können und auf die Werte, die in Slate-XNS vergeben wurden, also etwa VLAN-ID 3 und Priority Code Point 7, einzustellen.
Konfiguration des Subscribers/Listeners in Automation Studio
Wie beim Vorgehen für die Publisher-Seite, gilt es für die Subscriber-Seite wieder eine OPC-UA-Konfiguration zu erstellen, in der die Ziel-Variablen einzutragen sind. In der Pub/Sub-Konfiguration müssen die Einträge (Multicast-Adresse, Port, Publisher-Id und die VLAN-Einstellungen) mit denen des Publishers übereinstimmen. Das Erstellen der „Reader-Group“ kann mit Hilfe der exportierten „.uabinary“-Datei durch Rechtsklick auf den Eintrag „Reader Groups“ -> „Import uabinary“ geschehen. Alle nötigen Parameter und die Reihenfolge der DataSet-Variablen werden automatisch übernommen und lassen sich den SPS-Variablen zuweisen.
Konfiguration des Subscribers/Listeners in TwinCAT
Zur Erstellung eines Subscribers für die Beckhoff-Steuerung in TwinCAT ist das Modul OPC-UA-Pub/Sub für TwinCAT nötig. Nach dem Erstellen des Projektes muss unter dem Punkt „I/O->Devices“ ein „Real-Time OPC UA Device“ angefügt werden und unter dem Reiter „Settings“ im Bereich „Offline Management“ eine „.uabinary“-Datei importiert werden. Dadurch legt TwinCAT automatisch alle relevanten Objekte mit den korrekten Einstellungen an und die OPC-Variablen lassen sich mit den SPS-Variablen verknüpfen.
Die Messergebnisse
Nach den beschriebenen Konfigurationen ließen sich die zum Test generierten Datenströme – einzelne I/O-Daten der Steuerungen – ohne weitere Probleme übertragen. Zur Auswertung des aufgebauten Netzwerks erfolgten verschiedene Betrachtungen, bei denen das Netzwerk teilweise durch zusätzliche Datenströme belastet wurde: So erfolgte ein UDP-Packet-Flooding mit 50 µsec Interpacket-Delay, fixer Länge von 1472 Bytes und 75% Auslastung der Bandbreite im Uni- sowie Multicast. Hierbei ergaben sich folgende Übertragungszeiten:
- Übertragungszeiten/Jitter ohne zusätzliche Netzwerklasten:
Standardabweichung: 17 µSekunden
Maximaler Jitter: 198 µSekunden (einzelnes Paket) - Übertragungszeiten/Jitter mit zusätzlichen Netzwerklasten:
Standardabweichung: 19 µSekunden
Maximaler Jitter: 192 µSekunden (einzelnes Paket)
Insgesamt bestätigt sich damit die von TSN angepeilte Vision eines konvergenten Netzwerkes, in dem sowohl Echtzeit- also auch „Standard“-Netzwerkteilnehmer in ein und demselben Medium ohne Einschränkungen gemeinsam kommunizieren können.
Ein Resümee
Die Autoren: Prof. Dr. Josef Griesbauer (links) ist Professor für Automatisierung und Meßtechnik an der Hochschule Kempten, Alexander Sturm ist Student im Abschluss der Bachelorarbeit an der Hochschule Kempten.
© HS KemptenSowohl B&R als auch Beckhoff haben ihre Hausaufgaben, trotz der noch zum Teil undefinierten TSN-Standards, gemacht: sowohl die Konfiguration als auch der Betrieb eines echtzeitfähigen Pub-Sub-Netzwerks über TSN sind möglich. Gleichermaßen zeigt sich noch der Stand des unfertigen Standards: viele Wege müssen mit zusätzlichen Tools – Slate XNS, OPC UA-Client – und mit selbst erarbeitetem Grundlagen-KnowHow gegangen werden. Unabhängig davon demonstriert dieses Anwendungsbeispiel, dass die Zukunft bereits offen steht für die Nutzung von TSN und PubSub.
|
Die Vorteile von TSN |
|---|
|
Die in den letzten Jahren als Industrial Ethernet etablierten Technologien, wie Profinet, Ethernet Powerlink oder Ethercat, werfen die Frage auf, welchen Vorteil das IEEE802-TSN noch bieten kann. Im Gegensatz zu Profinet oder Powerlink arbeitet das 802-TSN direkt auf der Data-Link Ebene des ISO-OSI-Modells, also unterhalb des IP-Stacks, und bleibt dennoch, anders als Ethercat, komplett kompatibel zu anderen Ethernet-Geräten. Das ermöglicht das Erstellen von konvergenten Netzwerken, also Netzwerken, welche sowohl deterministische Steuerungsdaten als auch unwichtigere weitere Datenströme über das gleiche Medium leiten können. Ein ganzes Automatisierungsunternehmen könnte so in einem einzigen Netzwerk realisiert werden: über das gleiche Netzwerk würden Maschinen sicher und echtzeitfähig kommunizieren, Arbeitsplatzrechner direkt auf Steuerungen, Sensoren oder Aktuatoren zugreifen und die gesamte Office-Kommunikation abgehandelt. Die volle Bandbreite des Ethernet könnte genutzt werden und größere Datenströme innerhalb einer Maschine oder zwischen Maschinen und anderen Teilnehmern im Netzwerk realisieren. Ganz im Sinne von Big Data und den großen Datenmengen, die bei Industrie-4.0 zum Beispiel für prädiktive Instandhaltung oder maschinelles Lernen notwendig sind. Insgesamt führt das zu einem großen Vorteil in Form eines offenen und Branchen-übergreifenden Standard, in dem alles Vorhandene auf höheren Schichten des OSI-Modells, einfach auf eine Verwendung von TSN adaptiert werden kann. |
Das könnte Sie auch interessieren
Ein gemeinsamer Testplan für das Industrie-Profil
Die Avnu, CLPA, ODVA, OPCF and PI kooperieren, um für das entstehende TSN-Profil IEC/IEEE 60802 der Industrie Automation einen einheitlichen Testplan zu generieren. All die Organisationen sollen damit ihre Produkte auf Konformität mit dem neuen...
mehr...Fokus liegt auf Interoperabilität
Testbeds spielen eine entscheidende Rolle bei der Entwicklung von TSN hin zu einem herstellerübergreifenden Ökosystem. Welche Fortschritte machte das TSN Testbed am ISW in den letzten Jahren, welche aktuellen Herausforderungen werden dort zur Zeit...
mehr...Call for Papers – bis 29. April Vorträge einreichen
Die TSN/A Conference hat sich zu ‚der‘ internationalen Informations- und Diskussions-Plattform für Echtzeit-Ethernet schlechthin entwickelt. Werden Sie Teil der Community und reichen Sie Ihren Vortrag zu der Präsenz-Veranstaltung am 28. und 29....
mehr...Verteilte Echtzeit-Applikationen auf TSN-Basis
Time-Sensitive Networking (TSN) ist eine der Schlüsseltechnologien für zukünftige verteilte Echtzeit-Anwendungen. Neben der eigentlichen TSN-basierten Kommunikation muss für eine erfolgreiche Umsetzung das Ökosystem und dessen Komponenten betrachtet...
mehr...Einheitlicher Standard für die Echtzeit-Datenkommunikation
Automatisierung und Vernetzung sind Grundvoraussetzungen für die Industrie 4.0. Unabdingbar ist dabei eine zuverlässige Datenkommunikation bei hohen Übertragungsraten. TSN trägt dazu bei, IT und OT zu einem einheitlichen Netzwerk ohne...
mehr...Multi-Vendor Demo feiert Premiere
Drei Jahre nach ihrem Start hat die Field Level Communications (FLC) Initiative der OPC Foundation jetzt den zweiten Release Candidat fertiggestellt – eine Multi-Vendor Anlage belegt die Fortschritte.
mehr...Virtualisierte Steuerungen mittels TSN-Backbone
Große Herausforderungen bei der Umsetzung virtualisierter Steuerungen sind die Skalierbarkeit und Konnektivität hin zur Feldebene. Dass sich das heute schon mittels eines TSN-Netzwerkes realisieren lässt, zeigt eine Umsetzung am ISW.
mehr...TSN im Verbund mit EtherCAT
TSN ist ein wichtiger Baustein für die konvergente Kommunikation in der flexiblen Produktion. Für den Übergang ist die Beherrschung und Integration bestehender Feldbustechnologien wie EtherCAT ein wichtiger Bestandteil. Eine Bestandsaufnahme, was...
mehr...TSN – Backbone für virtualisierte Steuerungen?
Sie steht derzeit als große Vision im Raum: Die Virtualisierung von Steuerungen. Dieser und der nächste Artikel dieser Serie gehen auf dieses Thema ein. Entscheidende Voraussetzung und Inhalt dieses Artikels ist die Konnektivität der Steuerung bis...
mehr...