TSN-Serie Teil 15
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 werden.
Bei den als TSN bekannten Erweiterungen der Ethernet-Standards handelt es sich um Kommunikationstechnik auf den unteren Schichten des OSI-Modells. Das branchenübergreifende Interesse an der Technologie sowie den damit verbundenen technologischen Visionen hat seinen Ursprung jedoch in den durch TSN befähigten verteilten (Echtzeit-) Applikationen. Diese zeichnen sich dadurch aus, dass sie auf mehrere lokale Applikationen auf physikalisch getrennten Geräten verteilt sind und durch ein echtzeitfähiges Netzwerk verbunden sind. Im industriellen Umfeld sind dies typischerweise Steuerungs- oder Überwachungsaufgaben, im Automotive-Bereich beispielsweise die Fahrzeugsteuerung oder das Infotainment. Potenziell können sich mehrere unabhängige Applikationen eine Infrastruktur – sowohl Netzwerk als auch Endpunkte – teilen.
Anwendungsfall aus der Industrie
Wie sieht ein praxisnahes Anwendungsszenario einer verteilten Echtzeit-Applikation in einem TSN-basierten Ökosystems aus, das TSN und weitere aktuelle Technologien wie die Virtualisierung mittels Container nutzt?
Angenommen werden drei Montagestationen, welche jeweils über einen zwei-Achs-Manipulator verfügen und mittels SPS-Steuerungen angesteuert werden. Anders als heute üblich sollen die SPS-Steuerungen nicht als einzelne Geräte, sondern als virtuelle Steuerungen (vPLC) auf einer Edge-Plattform realisiert sein. Als Plattform kommt dabei ein Linux-PC mit Real-Time Patch (Preempt-RT) zum Einsatz. Die einzelnen Antriebsregler sind als Embedded Devices ausgeführt. Zwischen den vPLCs und den Embedded Devices werden dabei echtzeitkritische Soll- und Istwerte im 1-ms-Takt ausgetauscht. Zusätzlich dazu können im Netzwerk weitere Daten sporadisch transportiert werden, wie Parameter oder Zustandsdaten für die Verwendung in einem Monitoring-system der Produktion.
Auf den oberen Protokollschichten kommt OPC UA PubSub für die Echtzeitdaten sowie Client Server für sonstige Daten zum Einsatz. Potenziell könnten hierfür zukünftig Ergebnisse der FLC Initiative zum Tragen kommen.
Zum Transport der verschiedenen Daten im selben Netzwerk dient TSN, wobei die Echtzeit durch die Nutzung eines zeitbasierten Schedules mit Streams und Datenklassen erreicht wird. Hierfür wird unter anderem 802.1Qbv genutzt. In dem hier exemplarisch beschriebenen Fall besteht dieser Schedule aus insgesamt drei Klassen: Eine für den isochronen Austausch der Soll- und Istwerte (ISO), eine für den priorisierten Transport von Parametern (PRIO) und eine weitere Klasse für das Senden von Monitoring Daten nach dem Best-Effort-Prinzip (BE).
Die Applikation soll von einem Engineering-Tool konfiguriert, deployed, verwaltet und überwacht werden. Eine zentrale Aufgabe dabei ist die Konfiguration der TSN-basierten Kommunikation, welche durch die CUC (Central User Configuration) realisiert wird. Diese hat die Aufgabe, die vom Anwender festgelegten Kommunikationsverbindungen an das zentrale Netzwerkmanagement weiterzuleiten und anschließend die sich ergebenden Konfigurationen an die Endgeräte – in diesem Fall die vPLCs und Embedded Devices – zu übergeben. Die Kommunikation zwischen den Endgeräten und der CUC ist applikationsspezifisch, weshalb im gegebenen Fall hierfür ebenfalls eine Lösung auf Basis von OPC UA zum Zuge kommt.
Das Netzwerk als solches wird mittels des zentralen Konfi-gurationsansatzes von TSN gemanagt, wofür ein zentrales Netzwerkmanagement – Central Network Controller (CNC) – zur Konfiguration der Infrastrukturkomponenten (zum Beispiel Switche) genutzt wird.
Komponenten einer verteilten Echtzeit-Anwendung
Das Ökosystem einer TSN-basierten Echtzeit-Anwendung basiert, wie auch im repräsentativen Anwendungsfall dargestellt, aus einer Vielzahl an Komponenten, welche im Folgenden einzeln betrachtet werden.
Die Applikation
Als erste Komponente wäre da die verteilte Echtzeit-Anwendung als solche. Sie setzt sich aus mehreren lokalen Applikationen und der Kommunikation zwischen diesen zusammen. Die lokalen Applikationen entsprechen typischen Echtzeit-Applikationen, sind jedoch auf eine gemeinsame Master-Zeit synchronisiert. Die Entwicklung als solche, sowie nutzbare Systemumgebungen unterscheiden sich hierbei kaum von klassischen Echtzeit-Applikationen. Entscheidend sind insbesondere die genutzten Betriebs- oder Laufzeitsysteme wie etwa Linux mit Preempt-RT Patch sowie potenziell echtzeitfähige Containerlösungen.
Die Schnittstellen zwischen den einzelnen lokalen Applikationen müssen sowohl hinsichtlich der zu übertragenden Daten als auch bezüglich deren Eigenschaften spezifiziert werden. Die Randbedingungen für die Datenübertragung gilt es, in Form von sogenannten Quality of Services (QoS) festzulegen. Hierzu zählen unter anderem das Übertragungsintervall, die Paketgröße sowie der frühest- und spätestmögliche Offset des Intervall-Startzeitpunktes für das Senden einer Nachricht.
Für die Übertragung der Nachrichten eignet sich beispielsweise OPC UA, insbesondere durch die Einführung der Publish-Subscribe (PubSub) Spezifikation Part 14. Hierdurch ist es der Anwendung möglich, Daten in einem festlegbaren Intervall bereitzustellen (publishen). Weitere Applikationen wiederum abonnieren (subscriben) diese Nachricht und erhalten somit in regelmäßigen Abständen neue Werte. Als Übertragungsprotokolle kommen dabei UDP, AMQP und MQTT zum Einsatz. Die Spezifikation Part 22 soll zukünftig unter anderem eine Beschreibung der TSN-Datenströme (Streams) sowie der QoS als Nodeset für OPC UA ergänzen.
Für die Integration eines OPC UA Stacks in Applikationen bieten sich verschiedene Lösungen an, beispielswiese die quelloffene Bibliothek open62541.
|
Das große Ganze im Fokus |
|---|
|
In den bisherigen Teilen unserer TSN-Serie haben wir verschiedenste Aspekte von TSN beleuchtet: von der Zeitsynchronisation, über die Konfiguration bis hin zu Endpunktlösungen. Technologisch sind diese Themen hochrelevant, ein nutzbares Produkt oder funktionierender Business-Case ergeben sich hieraus jedoch noch nicht. Nichtsdestotrotz wird TSN branchenübergreifend als Schlüsseltechnologie für zukunftsweisende Innovationen gesehen. Wie bei jeder Basistechnologie ist das Gesamtsystem drum herum entscheidend für den Erfolg. In dieser Ausgabe soll dieser Systemansatz analysiert und strukturiert werden. Interessierte gewinnen so neben einem Systemverständnis für TSN-Applikationen einen Einstiegspunkt für eigene geplante Implementierungen. Zusätzliche Klarheit, wie sich solche Ökosysteme ausgestalten lassen, aber auch Informationen zu konkreten Anwendungen können wir uns noch in diesem Jahr von verschiedenen Seiten erhoffen: Einerseits – wie in der Ausgabe 9/2021 der Computer&Automation berichtet – von den Profilen und andererseits auch anwendungsseitig von den Arbeiten im Rahmen der FLC-Gruppe der OPC Foundation und weiteren Organisationen. Wie immer freuen wir uns über Rückmeldungen, Kommentare oder Anregungen zu dieser Artikelserie! Schreiben Sie uns: redaktion[at]computer-automation.de Meinrad Happacher und Stefan Frick |
Endpunkt und Infrastruktur
Die einzelnen lokalen Applikationen werden auf jeweils eigene (physikalische) Endgeräte verteilt. Die gesamte Infrastruktur, bestehend aus den Endgeräten sowie der dazwischen liegenden Kommunikationsinfrastruktur, stellt einen weiteren, hier zu betrachtenden Aspekt dar.
Die Endpunkte, im beschriebenen Anwendungsfall die Edge Plattform, die Embedded Devices sowie die Switche (und sonstige Infrastruktur-Komponenten) müssen entsprechend den Anforderungen der Anwendung und der Kommunikation konfiguriert werden können, damit die Daten zur richtigen Zeit vom Gerät weitergeleitet werden.
Unter Linux existieren hierfür verschiedene Queuing Disciplines (qdiscs). Durch die Aufteilung des Traffic auf mehrere Buffer sowie den Einsatz weiterer Mechanismen kann die Datenkommunikation (zeitlich) gesteuert werden.
Bei strikten zeitlichen Anforderungen empfiehlt es sich, auf TSN-fähige Hardware zurückzugreifen. Neben einer Unterstützung der Zeitsynchronisation mittels Hardware-Clock können insbesondere spezielle Sendemechanismen vorteilhaft für die Präzision sein, wie sie beispielsweise von den Intel-Chips i210 oder i225 geboten werden. Eine umfassende Endpunktlösung für den Einsatz von TSN und OPC UA auf Endgeräten gibt es schon: Sie wurde in dem Projekt Access-TSN entwickelt und steht quelloffen zur Verfügung.
Engineering der verteilten Echtzeit-Applikation
Die konkrete Verteilung der Anwendung im Netzwerk und die Festlegung der Kommunikationsstrecken erfolgt mittels Engineering. Dies kann beispielsweise in einem geeigneten Tool durch einen Anwender erfolgen. Analog zu bekannten Engineering-Tools aus der industriellen Steuerungstechnik kann in einem ersten Schritt das Netzwerk nach angeschlossenen Geräten durchsucht werden (Topologie-Ermittlung). Anschließend erfolgt das Mapping der einzelnen Applikationen – im Beispiel die Applikationen der Steuerungen sowie der einzelnen Antriebe – auf die jeweiligen Endgeräte im Netzwerk. Ist die Anwendung verteilt, gilt es noch die Streams zu definieren. Eine mögliche Handhabung hierfür ist die visuelle Darstellung des Netzwerkes in dem Engineering Tool und eine durch Drag-and-Drop festlegbare Verbindung zwischen zwei Endgeräten. Anhand zusätzlicher Einstellungen – etwa Prioritäten– werden diese Ströme durch den Anwender weiter spezifiziert.
Geeignete Tools hierfür sind bislang proprietäre Eigenentwicklungen. Denkbar und vor allem wünschenswert ist hierbei zukünftig eine offene Lösung, die entweder ein komplettes Tool bereitstellt oder zumindest notwendige Funktionen zur Erweiterung bestehender Engineering Tools bietet.
Der Autor: Stefan Oechsle ist wissenschaftlicher Mitarbeiter am Institut für Steuerungstechnik (ISW) Stuttgart.
© ISWDie Bereitstellung
Die Übertragung der Applikationen auf die jeweiligen Endgeräte und deren letztliche Ausführung kann zwar manuell erfolgen, moderne Konzepte – Stichwort: Container und Virtualisierung – bieten hier jedoch einige Vorteile gegenüber dem herkömmlichen Ansatz. Statt geeignete Hardware für die Ausführung einer speziellen Applikation zu kaufen, kann eine solche Applikation auch in Containern auf handelsüblicher Hardware ausgeführt werden. Per Virtualisierung lassen sich dabei verschiedene Systeme und Hardware entsprechend den Anforderungen emulieren. Derartige Ansätze steigern die Modularität und insbesondere die Flexibilität in großem Maße.
Durch das Kapseln einer Applikation in Containern ist diese weitestgehend unabhängig vom restlichen System. Zudem ist das Ausrollen der Applikation auf einem Gerät (Deployment) relativ einfach: wenige Kommandozeilenbefehle reichen aus, um den gewünschten Container aus einem Repository zu laden, auf dem Gerät zu instanziieren, notwendige Abhängigkeiten zu installieren und den Container sowie die Applikation zu starten.
Verbreitete und vor allem offene Systeme für die Containerisierung sind Docker und Kubernetes.
Die Netzkonfiguration
Die bislang durchgeführten Schritte führen allerdings erst zu einer funktionsfähigen, verteilten Echtzeit-Anwendung, wenn letztlich das Netzwerk noch korrekt konfiguriert wird. Bezüglich der Netzkonfiguration sieht TSN im Standard IEEE 802.1Qcc drei grundlegende Ansätze vor: Zentral, dezentral sowie hybrid. Der zentrale Ansatz sieht ein zentrales Netzwerkmanagement mittels CNC vor. Dieses ist mit allen Switchen im Netz verbunden und kennt somit die Topologie. Die CUC hingegen kann als Vermittler zwischen CNC und den End-geräten verstanden werden. Die Endgeräte – oder ausgelöst durch den Anwender, beziehungsweise das Tool – übermitteln ihre Anforderungen an die CUC. Von dort werden sie zur Berechnung an die CNC übertragen. Die daraus erhaltenen Konfigurationen werden von der CUC abschließend zurück an die Endgeräte gesendet und dort bereitgestellt. Zusätzlich konfiguriert die CNC entsprechend die beteiligten Switche.
Im dezentralen Ansatz existiert kein zentraler Netzwerk-controller mit Kenntnissen über die Infrastruktur. Die Konfiguration erfolgt hierbei durch entsprechende Protokolle, etwa durch das SRP (Stream Reservation Protocol) oder das RAP (Resource Allocation Protocol). Die Informationen der Streams werden mittels des entsprechenden Protokolls an sämtliche Teilnehmer der Infrastruktur übermittelt.
In IEEE 802.1Qcc sind bereits grundlegende Strukturen der zu übermittelten Informationen für die Konfiguration zwischen CUC und CNC definiert. Im noch nicht abgeschlossenen Standard 802.1Qdj werden diese Strukturen zu einem vollständigen Interface mittels RESTCONF erweitert.
Der hybride Ansatz stellt eine Mischung der beiden Varianten dar, ist bisher jedoch der am wenigsten weit standardisierte und wird daher hier nicht betrachtet.
Monitoring und Diagnose
Der ControlTSN Ansatz: Die Baukasten-Struktur soll eine individuelle Nutzung des Frameworks gewährleisten.
© ISWDie beschriebenen Komponenten zur Entwicklung, Verteilung und Deployment der Applikation sowie zur Konfiguration des Netzwerkes führen zu einem lauffähigen System.
Damit eine korrekte Funktionsweise gewährleistet ist, empfiehlt es sich, das System zu überwachen. Von besonderer Bedeutung sind hierbei die Synchronisation der Geräte sowie die Eigenschaften der Echtzeit-Kommunikation. Die Genauigkeit der Synchronität zwischen den Endgeräten lässt sich mittels des Reverse Sync-Verfahrens ermitteln. Es werden dabei einzelne Slaves – Endgeräte – jeweils in einer eigenen Domain als Grandmaster festgelegt. Durch das Senden von Sync-Nachrichten an den primären Grandmaster kann dieser den zeitlichen Offset der Endgeräte berechnen. Aus dem Jitter der Offsets ergibt sich wiederum die Genauigkeit der Zeitsynchronität.
Bei der Überwachung der Echtzeit-Kommunikation sollte die Latenz der übertragenen Daten betrachtet werden. Diese kann durch die Berechnung der Differenz zwischen dem Sendezeitstempel (Tx) und dem Empfangszeitstempel (Rx) eines Streams erfolgen. Aber auch der Jitter sollte überwacht werden.
Offene Referenzarchitektur
Die effiziente Entwicklung funktionsfähiger und stabiler TSN-basierter verteilter Anwendungen erfordert eine Kombination der beschriebenen Komponenten. Erst durch das Zusammenspiel dieser Komponenten lassen sich die drei notwendigen Sichten – Netzwerk-Engineering, Container-Engineering, Applikations-Engineering – abdecken.
Um Entwicklern zukünftiger Anwendungen und den zugehörigen Engineering-Tools eine Basis zu geben, wird in dem Projekt ControlTSN ein modulares Framework zur Umsetzung dieser Aspekte entwickelt. Zentrales Engineering sowie lokale Endpunkte dieser offenen Lösung stehen dabei gleichermaßen im Fokus. Die aufgezählten Komponenten spiegeln sich dabei in einzelnen Modulen wider, welche durch einen Framework-Kern integriert werden. Eine zentrale Daten- und Funktionsschnittstelle sorgt dabei für die notwendige Inter-Modul-Kommunikation. Der Fokus hierbei liegt explizit auf der Gestaltung eines Art Baukastens und keiner einzelnen Applikation oder eines einzelnen Produktes. Die Komponenten lassen sich so je nach individuellem Bedarf für zukünftige Projekte nutzen.
Das könnte Sie auch interessieren
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...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...
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...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...Vom TSN-Testbed zur wandelbaren Produktion
Das ISW in Stuttgart unterstützt mit dem TSN Testbed die Etablierung eines deterministischen und offenen Netzwerkstandards in Produktionsstätten. Florian Frick beschreibt den Status Quo.
mehr...TSN-Profile im Vergleich
In den unterschiedlichsten Branchen laufen die Arbeiten für TSN-Profile auf Hochtouren. Dieser Artikel der TSN-Serie beleuchtet die laufenden Arbeiten zu den Profilen für die Branchen Industrie, ProAV, Automotive und Aerospace.
mehr...Die Kombi macht´s!
Mit TSN lässt sich zwar eine hersteller- und plattformübergreifende Vernetzung realisieren. Doch erst in Kombination mit 5G wird die durchgängige Ende-zu-Ende-Echtzeit-Kommunikation auch für mobile Anwendungen und Cloud-Anbindung möglich.
mehr...Ein Evolutions-Update
TSN ist nüchtern betrachtet eine Weiterentwicklung der IEEE Ethernet-Standards. Andererseits ist TSN die Basis für revolutionäre Veränderungen in der industriellen Kommunikation. Wie ist der Status quo der TSN-Entwicklungen? Welche...
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...