TenAsys - TSN-Serie Teil 20
Ein ressourcenbasierter Ansatz
Der Mehrwert von TSN ergibt sich vor allem durch die IT/OT-Konvergenz in den Endpunkten. Das Potenzial auszuschöpfen ist noch komplex und erfordert tiefe Kenntnisse der Netzwerktechnik. Als Alternative wird ein applikationszentrischer, ressourcenbasierter Ansatz vorgestellt.
Time-Sensitive Networking (TSN) erweitert Standard-Ethernet nach IEEE 802.1 um Funktionen für die Synchronisation und deterministische Datenkommunikation. Es gilt als Schlüssel für konvergente IT/OT-Netzwerke, welche die entscheidende Voraussetzung für die Digitalisierung der Produktion sind.
TSN arbeitet auf Schicht 2 des OSI-Modells und ist damit eine Datenverbindungstechnologie, die durch verschiedene Protokolle auf höherer Ebene genutzt werden kann. Seit dem Start der TSN-Aktivitäten, wurden mehrere verbreitete Ethernet-basierte industrielle Kommunikationsstandards dahingehend erweitert, dass diese zukünftig auf Basis eines TSN-Netzwerks operieren können, beispielsweise Profinet und CC-Link IE TSN. Auch auf Basis des bisher hauptsächlich an der IT/OT-Schnittstelle stark verbreiteten OPC UA soll unter Nutzung von TSN zukünftig eine direkte Feldkommunikation möglich sein, welche unter der Bezeichnung OPC UA FX standardisiert wird.
Die Vielzahl TSN-basierter Ansätze zur industriellen Kommunikation zeigen einerseits die breite Akzeptanz und unterstreichen die Notwendigkeit konvergenter Echtzeit-Netzwerke für die Digitalisierung. Andererseits sorgen die verschiedenen Ansätze auch für Irritationen bei den Anwendern, da diese die TSN-Standards verschieden nutzen und konfigurieren.
Die Entwicklung von TSN in den IEEE Task Groups und die damit verbundene Vision der IT/OT-Konvergenz mittels eines Standard Ethernet sind nun mehr als zehn Jahre alt. Da die Standardisierung von TSN sowie der überlagerten Protokolle nach wie vor laufen und Infrastruktur sowie Endpunkt-Hardware nur langsam auf den Markt kommen, sind reale Installationen bisher noch limitiert.
Die Herausforderungen
Trotz des großen Potenzials von TSN stellt die Nutzung Anwender vor viele Herausforderungen. TSN bietet eine große Anzahl an grundlegenden Funktionen für eine deterministische Kommunikation. Wie diese zu kombinieren sind, ist jedoch weder standardisiert noch gibt es einen allgemeinen Konsens. Insbesondere nutzen verschiedene TSN-basierte Protokolle unterschiedliche Ansätze. Auch die Konfiguration der gewählten Mechanismen ist nicht abschließend geklärt. Eine besondere Herausforderung stellen die Endpunkte dar: Deren Architektur liegt außerhalb des Fokus der IEEE 802.1 Standards, für eine saubere Trennung der Layer gibt es keine geeigneten Abstraktionsschichten und potentiell können auf einem physischen Endpunkt mehrere virtuelle Endpunkte realisiert sein.
Kombiniert führen die Faktoren, welche in Bild 1 zusammengefasst sind, zu einer hohen Komplexität. In Konsequenz müssen Unternehmen, die die Vorteile von TSN nutzen möchten, technische Experten hinzuziehen, die sich mit den Feinheiten der Technologie auskennen und wissen, wie sie für bestimmte Anwendungsfälle eingesetzt werden kann.
TSN aus Anwendersicht
Der Komplexität stehen die Wünsche der Anwender gegenüber. Verteilte Echtzeitanwendungen sollen sich einfach auf TSN-basierten Systemen umsetzen lassen. Hierzu müssen Funktionen zur Verfügung stehen, die deterministische Kommunikationsbeziehungen erstellen, verwalten und einfach nutzen lassen. Die Anwendung steht klar im Fokus: Lösungen für den Anwender erstrecken sich daher insbesondere auf die Endpunkte und das Applikationsengineering, wohingegen das Netzwerk entsprechend automatisch gemanagt werden muss. Das Fehlen entsprechender Lösungen für Endpunkte ist bis dato ein Hindernis für die Akzeptanz und die breite Adaption von TSN. Die Industrie benötigt eine Abstraktionsschicht, welche die Konfiguration von zeitkritischen Anwendungen und Endpunkten vereinfacht, um TSN für alle zugänglich zu machen.
Ein ressourcenbasierter Ansatz
Bild 2. Die verschiedenen Schichten im Endpunkt, sowie deren Kernfunktionen und Schnittstellen.
© TenAsysWährend Netzwerke im OT-Umfeld typischerweise sehr explizit entwickelt und betrachtet werden, werden diese in der IT meist als gegebener Teil der Infrastruktur gesehen und als eine verfügbare Ressource genutzt. Eine Ressourcenbetrachtung ist durchaus auch im OT-Umfeld möglich: Anstelle von Standards, Netzkonfigurationen und Low-level-Kommunikation können Anwender verschiedene Kommunikationsbeziehungen sehen. Was hierbei die Ressource ist, kann sich je nach Ansatz zur Verwendung von TSN unterscheiden:
- Physische Netzwerkschnittstellen
- Traffic-Klassen mit bestimmten deterministischen Garantien
- Streams mit garantierten deterministischen Eigenschaften
Auf Basis dieser Kommunikationsressourcen können Applikationen entwickelt werden, ohne tiefgehende Kenntnisse der Technologie zu haben. Voraussetzung ist jedoch, dass ein unterlagertes System diese Abstraktion umsetzt und sich um die notwendige Konfiguration kümmert.
Systeme bestehen grundsätzlich aus Hardware-Software-Kombinationen. TSN-fähige Hardware in Form von Netzwerk-Controllern kommt zunehmend auf den Markt und kann einen Teil der Funktionen umsetzen. Dabei ist jedoch zu beachten, dass es nicht „die“ TSN-Hardware gibt, sondern verschiedene Controller verschiedene Hardware-Unterstützung bieten, wobei stets komplementäre Softwarefunktionen notwendig sind. Ein besonders genaues Hinsehen ist bei den weit verbreiteten und genutzten Controllern geboten, die zwar verschiedene TSN-Funktionen effizient unterstützen, nicht jedoch speziell für den TSN-Einsatz entwickelt wurden (beispielsweise der I210 Ethernet-Controller von Intel). Entsprechend bedarf es zusätzlich zu den Softwarekomponenten eines großen Expertenwissens um diese sinnvoll einsetzen zu können. Aus Endpunkt-Sicht lassen sich drei Schichten identifizieren (Bild 2):
- Applikationsschicht
- Abstraktionsschicht
- Hardwareschicht
Zwischen den Schichten gibt es jeweils Schnittstellen. Von der Hardware zur Abstraktion werden die entsprechenden Hardware-spezifischen Schnittstellen genutzt, an der Schnittstelle zwischen Abstraktion und Applikation spiegelt sich der ressourcenbasierte Ansatz wider: Es gibt Kommunikations-Ressourcen zum Senden und Empfangen sowie Management-Schnittstellen für die Ressourcen.
Der ressourcenbasierte Ansatz erlaubt es, das gesamte System – von der Hardware bis zur Applikationsschnittstelle – mittels Ressourcen-Maps einheitlich abzubilden. Hierbei ist jeweils eine Map für die Sende- sowie Empfangsrichtung nötig. In Senderichtung werden – ausgehend von der physischen Schnittstelle, welche die Wurzel darstellt – die Ressourcen über verschiedene Shaper in immer neue Ressourcen aufgeteilt.
Es lassen sich dabei diese verschiedenen Shaper nutzen:
- Time-aware Shaper
- Credit-based Shaper
- Priority-based Shaper
- Stream-based Shaper
Diese können dabei exakt den jeweiligen TSN-Funktionen entsprechen, beispielweise dem Time-aware Shaper nach IEEE 802.1Qbv. Darüber hinaus können Shaper auch nur lokal im Endpunkt realisiert sein, um beispielsweise feingranulare Traffic-Klassen für eine größere Anzahl paralleler Applikationen im Endpunkt mit einem fairen Zugang zum Netzwerk ermöglichen.
In der Empfangsrichtung, welche ebenfalls durch eine Map beschrieben ist, werden die eingehenden Daten von der physischen Schnittstelle aus mittels Filter weiter aufgeteilt.
Die in den Maps definierten Ressourcen entsprechen der Anwenderschnittstelle. Der Anwender kann also verschiedene Entry-Points – von der physischen Schnittstelle bis zu feingranularen Traffic Klassen – wählen um seine Applikation zu realisieren. Die Konfiguration der Ressource-Maps ist dabei entscheidend für die Effizienz des Ansatzes. Abhängig von der Nutzung sind verschiedene Möglichkeiten vorgesehen:
- Statische oder Default-Konfigurationen
- (Teil-)Konfiguration mittels Schnittstellen zum zentralen oder verteilten Netzwerkmanagement oder Applikationsengineering
- Manuelle Konfiguration mittels APIs
- Nutzung spezifischer Konfigurationen für TSN-basierte Lösungen wie Profinet over TSN oder CC-Link IE TSN
Umgesetzt wird die Sende- und Empfangslogik in der Abstraktionsschicht sowie der Hardware, welche auf Basis der Maps konfiguriert werden.
TSN: Anwendungsbeispiel und Umsetzungsperspektive
Die Virtualisierung mehrerer Steuerungen ist ein typischer Anwendungsfall für TSN. Der Hauptvorteil dieses Ansatzes ist, dass mehrere virtuelle Steuerungen auf einem Multicore-Industrie-PC parallel laufen können. Anstatt also viele diskrete Hardware-Steuerungen einzusetzen und zu verwalten, können Anlagenbetreiber alle ihre Echtzeit-Steuerungsaufgaben auf einigen wenigen, leistungsstarken Multifunktions-Automatisierungssteuerungen konsolidieren.
Dieser Anwendungsfall soll der Illustration des ressourcen-basierten Ansatzes dienen. Es wird angenommen, dass drei Maschinen mit jeweils zwei Achsen mittels virtualisierter Steuerungen betrieben werden. Alle Steuerungen sollen auf demselben Endpunkt ausgeführt werden. Die Kommunikation zwischen den Steuerungen und den Antrieben setzt sich aus Echtzeit-Streams in beide Richtungen, zu priorisierenden Konfigurationsdaten, sowie Best-Effort Daten für Monitoring-Funktionen zusammen (Bild 3).
Zur Umsetzung der Kommunikation werden sowohl empfangs- als auch sendeseitig Ressourcen-Maps aufgestellt, welche verschiedene Shaper und Filter kombinieren (Bild 4). Basierend auf den Ressourcen erfolgt die Implementierung der eigentlichen Applikationen. Applikationsseitig wäre beispielsweise eine Nutzung der Stream-Ressourcen für OPC UA Pub/Sub Verkehr, die Nutzung der priorisierten Traffic-Klasse für OPC UA Client Server, als auch die Nutzung von Best-Effort für einen Zugang mittels webbasiertem Monitoring möglich.
Die Umsetzungsperspektiven
Der ressourcenbasierte Ansatz lässt sich in Echtzeitbetriebssystemen nutzen, erfordert aber tiefgehende Eingriffe in die klassische Netzwerkarchitektur. Dabei ist einerseits eine enge Kopplung mit der Zeitsynchronisation, als auch insbesondere mit dem Applikations-Scheduling erforderlich. Momentan wird der ressourcenbasierte Ansatz in das INtime RTOS von TenAsys integriert und erprobt.
Dieser Ansatz ermöglicht, Echtzeitapplikationen auf TSN-Basis zu entwickeln, ohne die Feinheiten von TSN-Komponenten, Traffic-Shaping und Timing-Offsets im Detail verstehen zu müssen. Stattdessen fungieren die INtime-Anwendungsentwicklungswerkzeuge und -Hilfsprogramme als Netzwerkkonfigurationsschnittstelle, die es ermöglicht, Lösungen auf der Anwendungsebene zu implementieren und deterministisch auszuführen - je nachdem, was der Anwendungsfall erfordert. Gleichzeitig lassen sich auf derselben Plattform Standard-IT-Workloads betreiben, beispielsweise über Windows, ohne mit den Echtzeitapplikationen zu interferieren.
Die in 2024 erwarteten Demonstratoren sollen nicht nur den Ansatz präsentieren, sondern auch einen wichtigen Beitrag zur plattformübergreifenden Abstraktion von Echtzeitapplikationen und deren Kommunikation leisten.
| TSN-Sightseeing auf der SPS |
|---|
|
Für Automatisierer gibt es vermutlich keinen besseren Ort als die SPS, der Messe in Nürnberg, um sich über die Trends und Entwicklungen der Branche zu informieren. Wir haben bei unseren Rundgängen auf der diesjährigen Veranstaltung insbesondere einen Blick auf die TSN-Trends geworfen: In den Vorjahren waren es relativ wenige Aussteller, die TSN auf ihren Ständen thematisiert haben – dafür taten sie dies sehr plakativ. Dies hat sich geändert. TSN wurde dieses Jahr nicht mehr so prägnant präsentiert, dafür aber auf wesentlich mehr Ständen. Bei jedem Chip-Hersteller gibt es nun TSN-fähige Hardware im Angebot – ob lediglich als MAC, integriert mit Prozessor, speziellen Lösungen beispielsweise für die Antriebstechnik oder als Switch-Lösung. Industrielle Switche mit TSN ergänzten vielfach diverse Endpunkt-Lösungen. Auch softwareseitig gibt es zunehmend Lösungen: Lösungen mit minimalem Footprint, offene Lösungen auf Linux-Basis oder integrierte RTOS OPC UA Varianten. Generell war TSN bei vielen Feldbusorganisationen als Ergänzung oder als alternativer Layer 2 zu sehen – bestätigt durch eine steigende Anzahl verfügbarer Produkte. Auch das kritische Thema Konfiguration rückten verschiedene Aussteller in den Fokus ihrer Exponate und gaben damit Einblicke in das Netzwerk- als auch Applikationsmanagement. Seitens der industriellen Steuerungen und Komponenten trauten sich die ersten Hersteller auch die Performance von TSN in den Fokus zu rücken, und jonglierten beispielweise einen Golfball mittels Seilkinematik. Zusammenfassend lässt sich sagen: Wir sahen deutlich weniger Marketing als in den vergangenen Jahren, dafür eine wesentlich größere Breite an und insbesondere auch Reife der TSN-Lösungen. Wie immer freuen wir uns über Rückmeldungen, Kommentare oder Anregungen zu unserer Serie. Ihr Florian Frick und Meinrad Happacher |
Das könnte Sie auch interessieren
Erstes TSN-Zertifizierungsprogramm
Das TSN-Zertifizierungsprogramm der AVNU ist das erste seiner Art, das Fähigkeiten im Zusammenhang mit Time Sensitive Networking (TSN) zertifiziert, insbesondere die von IEEE SA entwickelten 802.1 TSN-Standards.
mehr...Industrial Ethernet dominiert
HMS Networks führt jedes Jahr eine Marktanalyse über industrielle Netzwerke durch. Die neueste Studie zeigt, dass der Markt für industrielle Netzwerke weiter expandiert, mit einem erwarteten Wachstum von 7 % im Jahr 2024.
mehr...KI – Wegbereiter für TSN?
Welche Anforderungen stellt der Einsatz von KI an die Automatisierung und die Vernetzung? Bilden vielleicht die Mechanismen von Time Sensitive Networks in Kombination mit Profinet die optimale Architektur für Anwendungen der KI?
mehr...Enabler einer SW-definierten Produktion?
Digitalisierung wird oft auf die Erweiterung klassischer Systeme um digitale Dienste reduziert. Das eigentliche Potenzial aber liegt in einem digitalen Ökosystem, welches es im Rahmen des Software-defined Manufacturings zu etablieren gilt – TSN...
mehr...TSN – Der aktuelle Stand der Dinge
TSN ist die Erweiterung der IEEE-Ethernet-Standards um deterministische Quality-of-Service Mechanismen und damit Schlüssel-Enabler für die Digitalisierung der Produktion. Dieser Beitrag fasst aktuelle Entwicklungen zusammen und ordnet diese in den...
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...Lua - eine Alternative zur SPS-Programmierung?
Bei der Programmierung von Echtzeit-Anwendungen greifen Entwickler immer noch auf ihre gewohnten, allerdings oft auch komplexen Sprachen wie C und C++ oder auf die traditionelle SPS-Programmierung zurück. Eine interessante Alternative hierzu sind ...
mehr...Schaeffler baut Defence-Sparte aus
Celia Pelaz wird CEO bei STech Defence
Schaeffler besetzt die Führung ihrer Tochtergesellschaft STech Defence GmbH neu. Zum 1. Oktober 2026 übernimmt Celia Pelaz die Position als CEO „Defence & New Space“ und leitet künftig die Geschäfte des Unternehmens mit Sitz in München.
mehr...Flexibles analoges Mixmodul
Das Analog-Mixmodul 'AM 821' der S-DIAS-Serie von Sigmatek verfügt über acht analoge Differenzeingänge mit 16-Bit-Auflösung sowie zwei analoge Ausgänge.
mehr...