Bild 1: Der dezentrale Ansatz: das verteilte Konfigurationsmodell für TSN.

© Belden

OPC UA TSN kann auf diese grundlegenden Mechanismen der Netzkonfiguration aus dem TSN-Teilstandard IEEE Std. 802.1Qcc-2018 zurückgreifen. In diesem Standard sind zwei grundlegende Konzepte beschrieben. Eine dieser zwei Vorgehensweisen arbeitet verteilt: Hier erfolgt die Netzkonfiguration ohne zentrale Steuerungseinheit mittels eines Reservierungsprotokolls, beispielsweise dem Stream Reservation Protocol (SRP) oder des für TSN vorgesehenen Resource Allocation Protocol (RAP). Mittels des RAP werden die Informationen der TSN-Kommunikationsflüsse zwischen den einzelnen Geräten ausgetauscht, sowohl zwischen den Switches als auch den Endgeräten (siehe Bild 1). 

Bild 2: Der zentrale Ansatz: das zentralisierte Konfigurationsmodell für TSN.

© Belden

Die zweite Vorgehensweise arbeitet mit einer zentralen Konfigurations- und Verwaltungseinheit, der Centralized Network Configuration (CNC). Diese CNC ist mit allen TSN-Switches verbunden und steuert die Konfiguration der TSN-Mechanismen sowie das Ein- und Auslasten der TSN-Kommunikationsflüsse in einem TSN-Netzwerk. Die Endgeräte melden ihren Kommunikationsbedarf über eine Schnittstelle für Endgeräte, die Centralized User Configuration (CUC), an die CNC (siehe Bild 2). 

Bild 3: Der gemischte Ansatz: Das hybride Konfigurationsmodell für TSN.

© Belden

Diese CUC kann entweder ebenfalls zentral die Anforderungen verschiedener Endgeräte entgegennehmen oder auf Endgeräten implementiert sein. In einem zentral verwalteten Netz oder Netzbereich, einer TSN-Domäne, darf stets nur eine CNC vorhanden sein, die selbstverständlich fehlertolerant ausgelegt sein muss. Diese CNC kann wiederum mit (theoretisch) beliebig vielen CUCs oder Endgeräten zusammenarbeiten.

Das hybride Modell ist schließlich eine Mischform aus dem verteilten und dem zentralisierten Konfigurationsansatz. Hier fordern die Endgeräte zwar Netzwerk-Ressourcen etwa über RAP an und erhalten auf diesem Weg auch entsprechende Konfigurationsinformationen. Allerdings beruht die Berechnung dieser Konfigurationsinformationen nicht auf einem verteilt ausgeführten Algorithmus, sondern kann mit Wissen über das Netzwerk durch die CNC berechnet werden (siehe Bild 3)

Sowohl das verteilte als auch das zentralisierte Konzept haben Vor- und Nachteile und sind für teilweise stark unterschiedliche Nutzungsszenarien verschieden gut geeignet. Aus diesem Grund besteht für OPC UA und TSN die Notwendigkeit, beide Verfahren gleichrangig zu unterstützen und zu nutzen – und zwar nicht nur getrennt in unterschiedlichen Netzen, sondern auch in einem Automatisierungsnetz gleichzeitig. Allerdings muss pro Teilnetz – auch TSN-Domäne genannt – innerhalb dieses Teilnetzes ein Ansatz gewählt werden. Dies ermöglicht die maximale Interoperabilität zwischen den verschiedenen Herstellern und Geräten innerhalb eines großen Netzwerks. Aktuell wird allerdings noch kontrovers diskutiert, ob zukünftig die unterschiedlichen Ansätze komplett parallel in einer TSN-Domäne eingesetzt werden können oder ob weiterhin pro TSN-Domäne ein Verfahren gewählt werden muss.

Neben diesen offenen technischen Fragen, die die Arbeitsgruppen der OPC Foundation und der IEEE 802 noch beantworten müssen, steht eine weitere Frage im Raum: Welcher Hersteller von Netzwerk-Geräten beziehungsweise -Lösungen muss in Zukunft welche Konfigurationskomponenten zur Verfügung stellen, damit ein TSN-Netzwerk sicher und für den Anwender komfortabel einstellbar und nutzbar wird?

Wer liefert was?

Unabhängig davon, ob das zentralisierte oder das verteilte Konzept zur automatisierten Netzwerk-Konfiguration genutzt wird: Gerätehersteller, sowohl von Endgeräten als auch von Switches, müssen gewisse Grundvoraussetzungen erfüllen, damit sich diese Art der Konfiguration nutzen lässt.

Ein Hersteller reiner Endgeräte mit einem einzigen Netzwerk-Anschluss kann sich prinzipiell bedingt entscheiden, ob er ausschließlich das verteilte Konzept, ausschließlich das zentralisierte Konzept oder beide Konfigurationskonzepte in seinen Geräten unterstützen will. Beim verteilten Konzept muss der Endgeräte-Hersteller das RAP unterstützen. Für die Verwendung im zentralisierten Fall kann das Endgerät potenziell das Endgeräte-Kommunikationsprotokoll für die Kommunikation mit einer CUC wiederverwenden. Dies ist beispielsweise im Fall von OPC UA TSN angedacht.

Allerdings muss der Endgeräte-Hersteller in letzterem Fall davon ausgehen, dass eine CUC im Netzwerk vorhanden ist, die das von ihm für das Endgerät gewählte Konfigurationsprotokoll beherrscht und die Verbindung mit der CNC herstellt. Somit ist die Entwicklung einer CUC für einen Endgeräte-Hersteller in vielen Fällen unerlässlich, um seinen Anwendern eine Lösung aus einer Hand präsentieren zu können. Die Konfigurationsparameter und Protokolldetails für die TSN-Konfiguration sind standardisiert, um die Interoperabilität zwischen den unterschiedlichen Herstellern zu gewährleisten. Hersteller können jedoch zusätzliche Merkmale in der Kommunikation zwischen Endgerät und CUC implementieren, die Alleinstellungsmerkmale beinhalten – beispielsweise zusätzliche Diagnoseparameter und Design-Algorithmen in der CUC. Die Funktion und Interoperabilität des TSN-Netzwerks wird hierdurch nicht beeinflusst, da die CNC sowohl mit der CUC als auch mit den Switches nur über Standard-TSN-Parameter kommuniziert. Eine mögliche Vorverarbeitung in der CUC ist hiervon entkoppelt.

Kurz: Ein Endgeräte-Hersteller hat die Wahl zwischen den Verfahren und sollte bei Unterstützung der zentralisierten Konfiguration auch eine CUC bereitstellen – eine bindende Pflicht ist dies aber nicht, da für die TSN-Standardmechanismen oftmals eine CUC eines anderen Herstellers verwendet werden kann.

Für die Hersteller von Infrastrukturgeräten steht neben den Geräten selbst beim zentralisierten Ansatz die Bereitstellung einer CNC im Vordergrund. Infrastrukturgeräte sind Geräte, die Endgeräten den Zugang zum Netzwerk ermöglichen, also beispielsweise ein TSN-Ethernet-Switch oder ein Gerät mit eingebettetem Switch mit mehreren Ports. Die CNC beinhaltet zahlreiche Logik- und Auswertungsmechanismen, die von Infrastruktur-Herstellern heute oftmals bereits in Netzwerk-Management und Konfigurationssoftware eingesetzt werden. So bietet beispielsweise Industrial HiVision, die Netzwerk-Management-Lösung von Hirschmann, Informationen über die physikalische Topologie sowie die verfügbare Bandbreite an den einzelnen Netzwerk-Ports.

Bild 4: Ein komplexes TSN-Konfigurationsszenario: ein Verbund aus zentralisiert und verteilt konfigurierten Endgeräten.

© Belden

Daneben kann der Infrastruktur-Hersteller optional zusätzlich eine CUC bereitstellen – für den Fall, dass keine andere CUC im Netzwerk vorhanden ist. Weiterhin muss der Switch mindestens einen Mechanismus für die TSN-Konfiguration unterstützen. Entweder muss er die Konfigurationsprotokolle und Standard-TSN-Managementobjekte für die Verbindung mit der CNC bereitstellen oder er muss die Unterstützung für das verteilte Konfigurationsmodell beinhalten. Bei einem TSN-Infrastruktur-Switch ist ebenso eine Unterstützung für beide Mechanismen denkbar. Schließlich sind die Switche und das Netzwerk der Dreh- und Angelpunkt für die Interoperabilität zwischen den unterschiedlichen Herstellern.
Ein komplexer Anwendungsfall für ein TSN-Netzwerk mit automatisierter Konfiguration könnte also ein Verbund aus zentralisiert und verteilt konfigurierten Endgeräten sein, der zusammen mit einer CNC des Infrastruktur-Herstellers und mehrerer CUCs unterschiedlicher Endgeräte-Hersteller im gleichen Netz verwendet wird (siehe Bild 4).

Ob Anwendungsfälle mit dieser Komplexität allerdings wirklich in der Praxis auftreten und nötig sind, wird die Zeit zeigen. In den Arbeitsgruppen der IEEE 802 und des OPC UA FLC müssen einzelne Details noch geklärt werden, wie beispielsweise, ob eine Interaktion zwischen zwei Endgeräten über mehr als eine CUC hinweg möglich ist, wie es etwa in der Abbildung des komplexen TSN-Konfigurationsszenarios bei einer Ende-zu-Ende-Kommunikation zwischen der Steuerung des Herstellers 3 und des Herstellers 4 notwendig wäre.

TSN-fähige Switche

Mit OPC UA und TSN beginnt nun eine wichtige Spezifizierungsphase für die Kopplung des Ende-zu-Ende-Transportprotokolls mit den grundlegenden TSN-Mechanismen. Allerdings sind bereits heute erste serienreife TSN-Infrastruktur-Produkte verfügbar, oftmals allerdings noch auf Basis von programmierbaren Bausteinen wie FPGAs. Seit kurzem sind aber auch erste Switching ASICs großer Chiphersteller am Markt verfügbar. Entsprechend ist zukünftig mit einer kontinuierlich steigenden Marktdurchdringung TSN-fähiger Ethernet-Switche zu rechnen. Deshalb gilt es von Herstellerseite schon jetzt aktiv zu werden. Sobald entsprechend ertüchtigte Endgeräte in größerer Zahl verfügbar sind, wird es bereits eine ausreichende Verbreitung einer TSN-fähigen Netzwerk-Infrastruktur geben, um die ersten großflächigen Tests und den Betrieb von OPC UA und TSN zu ermöglichen. 

Weiterhin ist die TSN-Technologie selbst bereits in einigen Testinstallationen, beispielsweise des Industrial Internet Consortiums (IIC) oder des Labs Network Industrie 4.0 (LNI 4.0), initial erprobt. Sowohl das zentralisierte als auch das verteilte Konfigurationskonzept kann dort in Netzwerken mit Geräten unterschiedlicher Unternehmen demonstriert werden.

OPC UA und TSN profitiert somit direkt von der Grundlagenarbeit, die unterschiedliche Hersteller und Organisationen in den letzten Jahren betrieben haben.

Es geht nicht ohne Migration

Mit der Gründung der Field-Level-Communications-Initiative und der breiten Unterstützung aller großen Hersteller aus der industriellen Automatisierung ist OPC UA und TSN als universelles Kommunikationsprotokoll für die Zukunft gesetzt. Die für die Anwender offensichtlichen Vorteile gehen für die Hersteller mit größerer Investitionssicherheit in eine einheitliche Basistechnologie und der Möglichkeit einher, sich über Komfort, Features und Bedienfreundlichkeit zu differenzieren. Und genau in dieser Bedienfreundlichkeit liegt der Schlüssel zum Erfolg! TSN liefert zwar die Bausteine für die automatisierte Konfiguration. Diese müssen allerdings in den Produkten auch umgesetzt werden. Gleichzeitig müssen die Hersteller Strategien entwickeln, wie Anwender und Kunden in die neue TSN-Welt migriert werden. Der Weg, beispielsweise von Profinet zu Profinet@TSN mit OPC UA, um nur eines von vielen möglichen Beispielen zu nennen, muss für den Kunden, auch in Misch-Installationen, möglich und beherrschbar sein.

Der Netzkonfiguration kommt auch hier eine entscheidende Rolle zu. Während die Migration eine Herausforderung für die einzelnen Automatisierungsanbieter darstellt ist es von großer Wichtigkeit, dass alle Hersteller, sowohl von Infrastruktur- als auch von Endgeräten, in der OPC Foundation für die Ende-zu-Ende-Kommunika-tion und in der IEEE/IEC-60802-Arbeitsgruppe für das TSN-Kommunikationsprofil zusammen an den verbleibenden Bausteinen für die gemeinsame Basistechnologie der Zukunft arbeiten.

Autor: 
Oliver Kleineberg ist Global Chief Technology Officer für den Bereich Industrial Networking bei Belden.