Time-Sensitive Networking (TSN) erweitert Standard-Ethernet nach IEEE 802.1 um Funktionen für die deterministische Datenkommunikation, gilt als Schlüssel-Enabler für konvergente IT/OT-Netzwerke und ist somit entscheidend für die Digitalisierung der Produktion. Die Notwendigkeit als auch die grundlegende Eignung von TSN sind branchenübergreifend akzeptiert, große Unklarheit besteht aber hinsichtlich der konkreten Nutzung der Mechanismen, der Konfiguration und des Engineerings.
In Diskussionen werden regelmäßig technische und firmenpolitische Aspekte, aber auch Fragen, wie etwas konfiguriert werden soll und was das Ergebnis der Konfiguration sein soll, durchmischt. Dies führt zu Irritationen und hemmt den schnellen Fortschritt. Ein Großteil der Problematik lässt sich historisch begründen: Im industriellen Umfeld wird die Kommunikation traditionell als Bestandteil der Applikation gesehen und ist dieser untergeordnet. Entwickler sind es gewohnt, die Kommunikation auf Bit- und Byte-Ebene zu spezifizieren und die Kontrolle über das exakte Timing zu haben.

Dies steht im Widerspruch zu einem infrastrukturbasierten Ansatz, welcher Voraussetzung für die erfolgreiche und skalierbare Nutzung von TSN für die Digitalisierung ist. Vergleichbar zur Standard-IT nutzen Applikationen die Infrastruktur und interagieren mit dieser durch Management-Schnittstellen, eine direkte Kontrolle über diese besteht nicht. Da im industriellen Kontext meist verteilte Echtzeitanwendungen umgesetzt werden sollen – beispielsweise eine virtuelle SPS (vPLC) welche mit verteilten Sensoren und Aktoren interagiert – ist darin der größte Unterschied zu den Anforderungen in der IT zu finden: Der Determinismus, welchen die Infrastruktur erfüllen muss.

Die konvergente Infrastruktur

Bild 1. Der Workflow des Applikations-Engineerings.

© ISW

Die zukünftige, digitale Infrastruktur für produzierende Unternehmen steht zwar noch vor vielen technischen Herausforderungen und unterliegt verschiedenen Interpretationen, grundlegend herrscht jedoch Einigkeit hinsichtlich ihrer Struktur. Anstelle der IT auf der einen Seite und lose gekoppelten OT-Systemen auf der anderen Seite, rückt eine Infrastruktur, die gleichermaßen von IT- und OT-Applikationen nutzbar ist. Die zentralen Komponenten sind Rechenplattformen und Kommunikationsnetzwerke, die sich vom Feld bis in die On-Premise Cloud durchgehend erstrecken. Diese Infrastruktur muss dabei die deterministischen Anforderungen erfüllen. Dies gilt insbesondere in direkter OT-Nähe, zum Beispiel für Netzwerke zu Feldkomponenten, aber auch für die Rechenplattformen und die Konnektivität zu diesen, auf denen beispielsweise vPLCs ausgeführt werden sollen.
Von zentraler Bedeutung für die zukünftige Infrastruktur ist das Management, sowohl für die Rechenressourcen als auch für das Netzwerk. Letzteres muss systemweit und applikationsübergreifend in der Lage sein, die zur Verfügung stehenden Ressourcen auf Basis der Anforderungen der Applikationen zu verwalten und die Kommunikationsinfrastruktur zu konfigurieren. Im Kontext von TSN ist hier der Central Network Controller (CNC) zu nennen. Der CNC erhält von den Applikationen beziehungsweise deren Engineering-Systemen Anfragen zu benötigten Streams. Dazu übernehmen die Engineering Tools die Rolle einer Centralized User Configuration (CUC), die in IEEE 802.1Qcc beschrieben ist. Basierend auf diesen Anfragen allokiert die CNC Netzwerkressourcen, konfiguriert die Infrastruktur, beispielweise Switche, und informiert die CUCs über die genauen Kommunikationsparameter wie etwa Sendezeitpunkte. Durch die Zentralität der CNC bedingt, lassen sich die Ressourcen des Netzwerks optimal einsetzen.

Die Compute-Knoten im Netzwerk stellen Rechenkapazität zur Verfügung und ermöglichen es, flexibel je nach Anforderung, Software auf diese zu deployen und dort auszuführen. In Kombination mit einer dynamischen Erstellung von konvergenter Kommunikation, ermöglicht dies wandlungsfähige Produktionssysteme, die sich bedarfsgerecht durch Software definieren lassen, wie dies beispielweise beim Software-defined Manufacturing verfolgt wird.

Die grundlegende digitale Infrastruktur aus Compute, Kommunikation und Management kann durch weitere Entitäten ausgebaut werden. Ein Beispiel hierfür ist ein Repository, in dem containerisierte Applikationen abgelegt sind und von dort beim Deployment auf Compute-Knoten geladen werden. Zusätzlich ist eine Registry für das Onboarding von Komponenten im Netzwerk sinnvoll. Dadurch lassen sich hinzukommende oder getauschte Geräte automatisch in das Netzwerk integrieren, ohne eine manuelle Vergabe von IP-Adressen, Konfigurationen oder Ähnlichem.

Das Applikations-Engineering

Bild 2. Das GUI des prototypischen Engineering-Tools.

© ISW

Wie sieht der grundsätzliche Workflow des Applikations-Engineerings für verteilte Echtzeitapplikationen aus? Die Applikation gliedert sich in verteilte Tasks, die in einem definierten und deterministischen Zusammenhang miteinander stehen. Tasks können dabei hardwareunabhängig oder für ein spezifisches Gerät definiert sein. Ein typisches Beispiel dafür ist die vPLC-basierte Steuerung eines Förderbands mit verschiedenen Aktoren und Sensoren zum Detektieren, Manipulieren oder Abschieben von Werkstücken. Die vPLC ist hardwareunabhängig und kann auf geeigneten Platt- formen deployed werden, beispielsweise einem IPC oder Edge-System. Die weiteren Tasks sind die Schnittstellen und lokalen Steuerungen der Komponenten, beispielweise des Förderbands, eines Vision-Systems oder auch eines einfachen pneumatischen Aktors. Diese Tasks sind fest mit der Hardware verknüpft. Um die verteilte Echtzeitapplikation zu betreiben müssen die Tasks und Komponenten unter Einhaltung der deterministischen Anforderungen über ein Netzwerk miteinander kommunizieren.

Der schematische Ablauf beim Engineering einer verteilten Echtzeitapplikation ist wie folgt (Bild 1):

Im ersten Schritt werden die gewünschten Applikationen ausgewählt. Die Information der verfügbaren Applikationen kann dabei beispielsweise aus dem vorhin erwähnten Repository stammen. Anschließend gilt es, die geeigneten Compute-Knoten im Netzwerk auszuwählen, auf denen die jeweiligen Applikationen ausgeführt werden sollen. Dies ist manuell aber auch automatisch auf Basis der benötigten und zur Verfügung stehenden Ressourcen möglich. Daraufhin werden die Applikationen auf den gewählten Geräten deployt. Nun muss die Kommunikation, unter Angabe der benötigten QoS, zwischen den Applikationen definiert und durch das zentrale Netzwerkmanagement (z.B. CNC) berechnet werden. Die sich ergebende Konfigurationen sind abschließend auf die Geräte zu übertragen. So sollte sich die verteilte Applikation ausführen lassen.

Die Engineering-Tools

Bild 3. Die Eingabemaske zur Spezifikation der QoS-Parameter für einen TSN-Stream.

© ISW

Den beschriebenen Workflow müssen künftige Engineering-Tools ermöglichen; sie entsprechen grundlegend den derzeit genutzten Tools (z.B. für SPS-Steuerungen), unterschieden sich aber hinsichtlich einiger Aspekte. Inwiefern zeigt ein prototypisches Engineering-Tool (Bild 2). Das Tool stellt dabei kein vollwertiges Produkt dar, sondern zeigt vielmehr das ganzheitliche Engineering im Kontext zukünftiger Infrastrukturen und die relevanten Interaktionen auf. Die Hauptansicht zeigt eine Visualisierung der Topologie des Netzwerks und der verbundenen Geräte. Darin zu sehen sind zum einen die physischen Verbindungen zwischen den Geräten (Compute-Knoten, Switche) und zum anderen die Kommunikation der einzelnen Applikationen. Auf der linken Seite sind Informationen zu den TSN-Streams und weiterem, konvergenten Traffic, den Applikationen sowie den vorhandenen Geräten gelistet.

Aufgrund der Komplexität konvergenter Netzwerke und der Kommunikation, spielt die Bedienung solcher Engineering-Tools eine wichtige Rolle. Bei der Betrachtung des Work- flows für das Applikations-Engineering, lassen sich in dem Tool die gewünschten Applikationen aus der linken Liste per Drag’n’Drop auf die entsprechenden Compute-Knoten in der Topologie-Ansicht ziehen. Daraufhin öffnet sich eine Eingabemaske zur Spezifikation der Deployment-Parameter – etwa das CPU-Bindung oder die Thread-Priorität. Selbiges gilt auch für die Definition der Kommunikation: Durch Verbinden zweier Applikationen lässt sich eine Kommunikation zwischen diesen erstellen. Auch hier werden verschiedene Parameter zur Spezifikation der QoS abgefragt. Bild 3 zeigt dies für einen TSN-Stream. Auch One-to-Many (Publish-Subscribe) Kommunikationen lassen sich dabei durch das Hinzufügen weiterer Applikationen als Empfänger (Listener) anlegen. Durch das Speichern der Anfrage werden die Informationen im Hintergrund mittels eines Engineering Framework (siehe Web-Tipp) übermittelt. Das Framework übertragt die Anfragen anschließend an das Netzwerkmanagement – in diesem Fall an eine CNC – und übermittelt daraufhin den jeweiligen Endgeräten die berechneten Kommunikationskonfigurationen.

Eigenständige Umsetzung

Der Autor: Stefan Oechsle ist wissenschaftlicher Mitarbeiter Echtzeitkommunikation beim ISW.

© ISW

Damit Anwender ein solches Applikations-Engineering umsetzen können, darf das Engineering durch den User nicht vernachlässigt werden. Das dargestellte Engineering-Tool ist dabei eine reine Benutzeroberfläche zur Interaktion mit dem besagten Engineering Framework. Die einfach zu bedienende Oberfläche in Kombination mit dem zentralen Konfigurations- und Management-Framework verdeutlicht, wie zukünftige Engineering-Tools aussehen und funktionieren können. Wichtig ist: Die Komplexität des Gesamtsystems muss so weit wie möglich verborgen bleiben, damit eine Akzeptanz dieser neuen Technologien, Paradigmen und Herangehensweisen ermöglicht wird.