TSN ermöglicht die Nutzung einheitlicher Ethernet-Infrastruktur

Rahman Jamal (National Instruments): Die Bedeutung von TSN liegt klar auf der Hand: Es ist die erfolgreiche Konvergenz von zeitkritischen, nicht zeitkritischen und Datenstreaming-Anwendungen über ein einziges Netzwerk. Was die Controller-Controller-Kommunikation anbelangt, hat TSN die Nase vorn. Wo sich die Gemüter aber aufheizen, ist die Feldbusthematik. Feldbusse sind bereits im Einsatz und werden nicht einfach über Nacht verschwinden. Selbstverständlich gibt es aber Überlappungen bei den Anwendungsbereichen von OPC UA over TSN und existierenden Feldbuslösungen. Hier kommt es darauf an, wofür sich der Kunde entscheidet, wenn er die Vorteile von OPC UA over TSN wie Interoperabilität und Bandbreiten im Gbit-Bereich betrachtet. Fest steht, TSN kann anspruchsvolle hochperformante Anwendungen ebenso abdecken wie gängige kostengünstige Applikationen und hätte somit langfristig auch das Potenzial, klassische Feldbusse nach und nach zu verdrängen.

Dr. Oliver Kleineberg (Belden): Die klare Antwort ist ja. OPC UA, transportiert über TSN, ist eine leistungsfähige Gesamtlösung für eine universelle, herstellerneutrale Echtzeit-Kommunikation bis auf die Feldebene. Wir gehen davon aus, das OPC UA über TSN vor allem deshalb eine attraktive Lösung wird, weil sich Gerätehersteller zu diesem System bekannt haben, die in der Vergangenheit oft konkurrierende Echtzeit-Ökosysteme unterhalten haben. Viele Kunden werden diese gestiegene Investitionssicherheit honorieren. Aber auch bestehende Ethernet-Feldbus-Ökosysteme können von TSN als Transportmechanismus profitieren. Dies trifft insbesondere dann zu, wenn durch TSN ein Migrationspfad bewährter Technologie in TSN-Netze aufgezeigt wird, der über die Feldebene hinausgeht.

Peter Lutz (Sercos): Ethernet-TSN leistet einen Beitrag, um die Konvergenz herkömmlicher Echtzeit-Ethernet-Lösungen zu einer einheitlichen, standardisierten und durchgängigen Netzwerkinfrastruktur herbeizuführen. Die Verfügbarkeit von Standard-Ethernet-Komponenten mit integrierter Echtzeitfähigkeit macht spezielle Hardware-Implementierungen überflüssig. Zudem erlaubt Ethernet-TSN, dass verschiedene Ethernet-Protokolle in einer gemeinsamen Netzwerkinfrastruktur koexistieren können. TSN-basierte Lösungen, wie OPC UA TSN, werden sich zunächst in der Steuerungs- und Prozessleitebene etablieren, insbesondere dann, wenn Maschinen mit Steuerungen bzw. Maschinenperipherie unterschiedlicher Hersteller auf der Basis eines einheitlichen, unabhängigen und weltweiten Standards vernetzt werden sollen. Allerdings ist zu erwarten, dass TSN-OPC UA mittelfristig auch in die Feldebene Einzug hält, zumal die Übergänge zwischen Steuerungs- und Feldebene fließend sind, und nicht immer höchste Performance bei kürzesten Durchlaufzeiten und höchster Protokoll-Effizienz gefordert ist.

Martin Rostan (ETG): TSN-Technologien werden Ethernet um Echtzeit-Kanäle ergänzen und damit Fabriknetzwerke besser für Steuerungsaufgaben nutzbar machen. So erweitert TSN auch die Einsatzmöglichkeiten von Ethercat: ganze Netzwerke aus Ethercat-Geräten werden sich ohne Änderung der Slave-Geräte direkt an TSN-Domänen ankoppeln lassen, und Steuerungen können über eine TSN-Infrastruktur deterministisch Daten austauschen. TSN ist kein Feldbus und wird auch keiner werden – OPC UA übrigens auch nicht. Manche der weniger performanten Industrial-Ethernet-Systeme werden versuchen, mit Hilfe von TSN etwas schneller zu werden – allerdings zum Preis deutlich erhöhter Komplexität.

Sebastian Sachse (B&R): Die Kombination von OPC UA TSN ist weitaus mehr als ein reiner Feldbus. Die Herausforderungen, vor denen unsere Kunden stehen, sind mit Feldbussen nicht zu lösen. Der Markt fordert eine durchgehende Vernetzung aller Systeme. Das ist nur möglich, wenn alle Netzwerkknoten die selbe Sprache sprechen. TSN ist wichtig, diese Technologie gewährleistet die Echtzeitfähigkeit und die Qualität der Verbindung. Das alleine reicht jedoch für die durchgehende Vernetzung nicht aus. Erst die Kombination mit OPC UA ermöglicht, dass alle Netzwerkknoten die gleiche Sprache sprechen. Mit dieser Kombination werden sowohl die Anforderungen von heute als auch die von morgen abgedeckt – inklusive IT-Sicherheit.

Karsten Schneider (PNO/PI): TSN definiert lediglich einen Layer 2 für die Kommunikation, ist also nicht als Feldbusersatz zu sehen. Aber selbstverständlich bietet die Technologie große Chancen. So können damit in der Feldebene Standard-Ethernet-Controller eingesetzt werden. Dadurch profitiert der Anwender von den Entwicklungen im IT-Bereich, wie der höheren Bandbreite durch Gigabit-Ethernet. Gleichzeitig lassen sich mit TSN durchgängige synchrone Netzwerke für taktsynchrone Anwendungen realisieren. Bisher mussten solche Netzwerke separat realisiert und in den Geräten dedizierte Chips integriert werden. PI hat daher schon vor längerem beschlossen, TSN in Profinet zu integrieren. Damit in Zukunft alle Steuerungen und Feldgeräte reibungslos miteinander kommunizieren und sicher Daten austauschen können, läuft derzeit eine Reihe an Detailarbeiten, wie Standardisierung, Prüfverfahren und Zertifizierungen.

Arno Stock (Renesas): Das große Versprechen der TSN-Technologie ist Konvergenz, also die gemeinsame Nutzung einer einheitlichen Standard-Ethernet-Infrastruktur für verschiedene Anwendungen, von harter Echtzeit bis hin zur klassischen IT. Die Anwender sollen einen Mehrwert durch Flexibilisierung der Netzwerkstruktur ihrer Anlagen und Maschinen erfahren und das Investitionsgut ‚Netzwerk‘ universell und effizient nutzen können. Doch Industrie 4.0 fordert mehr als Koexistenz. Verschiedene Systeme sollen miteinander kommunizieren. OPC-UA ist schon heute etabliert, um herstellerunabhängig auf Prozess- und Maschinendaten zuzugreifen. Durch die Pub/Sub-Erweiterung eignet es sich in Zukunft auch für Echtzeit-Steuerungsaufgaben.

Georg Stöger (TTTech): TSN skaliert bis auf die Feldebene, weil es als Erweiterung von Ethernet die unterschiedlichen Bandbreiten und Topologien von Ethernet unterstützt – und auch zu Ethernet-Geräten kompatibel ist. Durch TSN werden die Eigenschaften von Ethernet um Anforderungen von maschinennaher Datenkommunikation wie Robustheit, Echtzeit und Sicherheit (Safety) ergänzt. So wird die Konvergenz von IT- und Cloud-Verbindungen mit industrieller Datenkommunikation wie Machine-to-Machine-Anwendungen möglich, aber auch die Anbindung von Feldelementen. Die Kombination von OPC UA mit TSN ist aus unserer Sicht ein heißer Kandidat für eine herstellerübergreifende Lösung und hat das Potenzial, Feldbusse auch bei komplexen Use Cases innerhalb von Maschinen tatsächlich abzulösen.

Robert Wilmes (Phoenix Contact): Für sich gestellt hat TSN keine Bedeutung für die Automatisierung. Erst mit überlagerten Applikationsschnittstellen bietet das Time Sensitive Networking eine gute Migration von heutigen Ethernet-basierten Feldbussen auf Standard-Ethernet. In Kombination mit OPC UA steht dann ein wirklich offener, von allen internationalen Herstellern akzeptierter Kommunikationsstandard zur Verfügung. Auf dieser Grundlage können heterogene Automatisierungsstrukturen aufgebaut werden, ohne dass beim Anwender Unsicherheit bezüglich der Verfügbarkeit seiner Anlage oder Maschine besteht. Die installierte Basis wird dabei zu Migrationsstrategien führen. Da OPC UA jedoch in immer mehr Geräte implementiert wird, ergibt sich daraus die logische Folge des Schritts von OPC UA mit TSN in die Feldebene.

elektro AUTOMATION: Erste Interoperabilitäts-Workshops haben stattgefunden. Als TSN-Ready-gekennzeichnete Managed Switche sowie TSN-ertüchtigte PC-Erweiterungskarten sind verfügbar. Doch wieweit ist die Standardisierung der einzelnen Teile für Hard- und Software (ASbt, Qbu, Qbv, etc.) vorangeschritten. Ist die Entwicklung von Lösungen auf dieser Basis schon heute möglich bzw. wann wird die Technologie in Seriengeräten verschiedener Hersteller für den Industrie-Einsatz verfügbar sein?

Beckmann: In der Standardisierung von TSN ist noch vieles in Bewegung. Einige für die Anbindung von Automatisierungskomponenten wichtige Standards sind aber bereits von der IEEE freigegeben und können somit in den Infrastruktur- und Endgeräten implementiert werden. Hierzu zählen beispielsweise der IEEE802.1Qbv-Standard zur Verbesserung des Weiterleitungsprozesses durch einen vorgeplanten und zeitgesteuerten Datentransfer (Time Aware Shaping). Und auch der Standard IEEE802.1AS-REV ist bereits in der Abstimmung innerhalb der IEEE – dieser definiert ein Protokoll zur Synchronisierung von zeitsensitiven Applikationen. Beckhoff ergänzt mit dem EK1000 sein Ethercat-I/O-System um einen Buskoppler, der die Anbindung von Ethercat-Segmenten über ein Ethernet-Netzwerk an eine abgesetzte Steuerung unterstützt. Die Implementierung der genannten TSN-Technologien (Qbv, AS-REV) stellt hierfür die Grundlage für einen deterministischen Datenaustausch zwischen der Steuerung und dem Segment bereit. Der Ethercat-TSN-Koppler, als erster Teilnehmer in einem Segment platziert, verfügt über zwei Ethernet-Schnittstellen. Einer dieser 100-Mbit/s-Port verbindet den Koppler mit dem Ethernet- bzw. TSN-Netzwerk. Den zweiten Port kann man optional für die Erweiterung zusätzlicher, abgesetzter Ethercat-Teilnehmer verwenden. Der EK1000 übernimmt dabei die Weiterleitung des Telegramms vom TSN- an den Ethercat-Port mit minimaler Durchlaufverzögerung.

Brandl: Mit der Verabschiedung der noch nicht abgeschlossenen Teile des TSN ist in 2018 zu rechnen. Parallel zur Standardisierungsarbeit realisieren wir Prototypen. Das herstellerübergreifende Zusammenspiel wird im TSN Testbed des Industrial Internet Consortium (IIC) regelmäßig überprüft. Unser OPC-UA-Client auf der Steuerung ist inzwischen als Produkt freigegeben. Damit können Kunden die Vorteile von OPC UA in der Kommunikation zwischen Steuerungen schon heute in Anwendungen nutzen, die keine Echtzeit erfordern. Außerdem haben wir einen Sercos-Softmaster freigegeben, der die Performance und Synchronität für anspruchsvolle Motion-Anwendungen erreicht. Diesen Sercos-Softmaster stellen wir als Open-Source-Lösung sogar frei von Lizenzgebühren zur Verfügung.

Hauser: Die Sammlung von Standards unter dem Label TSN ist vergleichbar mit einem Baukasten, der Mechanismen für verschiedenste Anwendungen von Automotive über Audio und Video bis hin zu Industrial Automation bereithält. Der Anwender kann die für ihn nutzbringenden Features implementieren, ohne auf die Fertigstellung weiterer, für ihn irrelevanter Standards warten zu müssen. 2018 ist für viele Hersteller das Jahr der TSN-Implementation und Interoperabilitätstests. Die wichtigsten Standards für industrielle Anwendungen sind bereits herausgebracht oder werden bis Mitte 2018 soweit sein. Schon heute sind komplette Industrielösungen marktfähig implementierbar und an Tools für die zentrale Provisionierung größerer Netze wird mit Hochdruck gearbeitet.

Jamal: NI ist in diesem Bereich sehr aktiv. Zum einen sind wir Gründungsmitglied des ersten TSN-Testbeds im Rahmen des IIC (Industrial Internet Consortium), in dem mehrere Hersteller ihre Implementierungen von TSN mit denen anderer Anbieter testen. Hier erfolgt die Prüfung eines gewissen Grads an Interoperabilität, was aber nicht zwangsläufig heißt, dass die Produkte dann auch den Standards entsprechen. Dafür wiederum gibt es Konformitätsprüfungen, in denen das Produkt auf Herz und Nieren geprüft wird. Dadurch soll sichergestellt werden, dass es die gesetzten Standards erfüllt. Selbstverständlich ist es wichtig, dass die Erkenntnisse aus den Testbeds auch entsprechend weitergereicht werden und in die Konformitätsprüfung, ggf. sogar in die Revisionen des Standards einfließen. Auch in diesem Bereich sind wir sehr aktiv, was alleine daran zu erkennen ist, dass wir Mitglied des Boards der Avnu Alliance sind, die für die Konformitätsprüfung von TSN zuständig ist. Die Basis für Testbeds und Konformitätsprüfungen sind natürlich TSN-fähige Produkte, von denen es aus unserem Hause bereits eine ganze Menge gibt. So haben wir etwa TSN-fähige CompactRIO-Controller, Ethernet-Chassis, Industrie-Controller und Datenerfassungsgeräte im Portfolio. Meines Erachtens dürfte dies eines der größten Portfolios an TSN-fähigen Produkten für die Mess-, Prüf-, Steuer- und Regelungstechnik auf dem Markt sein. In Bezug auf Industrielösungen erwarten wir für den Anfang, dass es weniger um komplette fabrikweite Neuinstallationen gehen wird. In den meisten Fällen wird TSN wohl in bereits bestehenden, so genannten Brownfield-Anlagen, implementiert, die im Übrigen auch den Schwerpunkt der Avnu-Aktivitäten bilden und wo die eben erwähnten Produkte zum Einsatz kommen.

Kleineberg: Die Spezifikation der IEEE 802.1-TSN-Standards, die neue Hardware erforderlich machen, ist abgeschlossen. Hersteller von Produkten können bereits entwickeln – ohne Angst haben zu müssen, auf ein bewegliches Ziel zuzuarbeiten. Im Bereich der Software-Spezifikationen sind einige Dokumente nahe der Fertigstellung, beispielsweise P802.1Qcc, das die zentralen und dezentralen Konfigurationsmodelle beschreibt. Andere Standards sind noch in einem frühen Stadium, beispielsweise das P802.1CS-Link-Local-Registration-Protocol. Diese können aber nach deren Fertigstellung per Software-Update nachgeliefert werden. Aus diesem Grund erwarten wir, dass schon 2018 erste Seriengeräte im Markt verfügbar werden.

Lutz: Da die meisten Ethernet-TSN-Substandards bereits freigegeben sind und TSN-fähige Hardwarekomponenten zur Verfügung stehen, können TSN-basierte Lösungen heute bereits entwickelt werden. Erste Prototypen auf Basis von Ethernet-TSN wurden bereits realisiert und beispielsweise in die Testbeds des IIC integriert. Allerdings wurde mit IEEE 802.1AS-rev ein grundlegender TSN-Substandard noch nicht endgültig verabschiedet. Und auch die OPC-UA-Spezifikationserweiterung für Publish/Subscribe ist zum aktuellen Zeitpunkt noch nicht abschließend freigegeben. Deswegen wird es noch ein wenig Zeit brauchen, bis eine breitere Auswahl an Produkten und Lösungen im Markt verfügbar ist und diese in realen Anwendungen eingesetzt wird.

Rostan: Das Thema Konfiguration ist noch eine richtige Baustelle, da man zurzeit das Netzwerk-Management auf eine andere Basis umstellt. Da die TSN-Standards überlappende Funktionen zur Verfügung stellen, benötigt man Profile für TSN-Infrastrukturgeräte, die regeln, was in konkreten Anwendungsfällen zu verwenden ist. Diese Profilbildung wurde von der IEC gestartet, wird aber erst 2019/2020 ausgereift sein. Trotzdem kann man ein Profil für Endgeräte schon definieren, so wie die ETG das für Ethercat bereits vorgelegt hat. Diese Spezifikation stimmen wir im Rahmen einer Liaison mit der IEEE802.1 Working Group ab, und durch die Ausprägung als Profil bleibt sie weitgehend stabil, auch wenn sich TSN noch ändert.

Sachse: OPC UA als Technologie ist heute als Standard in vielen Industrie-Lösungen implementiert und kommt bei unseren Kunden in Serie zum Einsatz. Die für unsere Industrie relevanten Standards von TSN sind ebenfalls verfügbar und in ersten Industrie-Lösungen auf Pilotbasis implementiert. Diese Pilotprodukte werden zudem in den Testbeds des IIC getestet und optimiert. In Kürze wird das auch in den Testbeds des LNI passieren. Sobald die Tests in den Testbeds abgeschlossen sind, werden erste Produkte mit OPC UA TSN in Serie gehen.

Schneider: Derzeit wird an der Spezifikation zur Nutzung von TSN mit Profinet gearbeitet, die Veröffentlichung ist im ersten Quartal 2019 geplant. Daher gibt es derzeit noch keine fertigen Produkte. Für unsere Mitglieder haben die Vorarbeiten jedoch längst begonnen, schließlich müssen sie ihre nächste Gerätegeneration mit TSN planen können. Derzeit laufen im Testbed des Labs Network Industrie 4.0 in Augsburg bereits viele Untersuchungen in Bezug auf Konfiguration und Kompatibilität, um einen Plug-&Work-Ansatz über eine standardisierte Schnittstelle zu ermöglichen. Aber für den Anwender ist es mit einer Spezifikation allein nicht getan. Gleichzeitig müssen auch Guidelines, How-to-use-Anleitungen etc. auf den Weg gebracht werden, genauso wie die Etablierung eines Testsystems und die Erarbeitung der Zertifizierung. Quasi begleitend werden im Augenblick Piloten und Prototypen entwickelt.

Stock: Die wesentlichen TSN-Substandards, die Hardwareunterstützung benötigen, sind verabschiedet. Vereinzelt sind bereits Lösungen auf FPGA-Basis verfügbar. Die Standardisierungsorganisationen konzentrieren sich nun auf Management und Konfiguration der Netze. Die Einführung von TSN wird schrittweise erfolgen. Im ersten Schritt hält TSN zusammen mit OPC-UA auf Steuerungs- (c2c) bzw. Maschinenebene (m2m) Einzug. Die Vorteile der direkten Interoperabilität von Maschinen sowie die Verfügbarkeit von Gbit-Übertragung überwiegen die heutigen Mehrkosten. Sobald Migrationspfade von den existierenden Industrie-Ethernet-Standards hin zu TSN definiert und Standardbausteine verfügbar sind, folgen im zweiten Schritt die Geräte auf der Feldebene. Es existieren bereits Bauteile, die TSN-Vorläuferstandards umsetzen. Diese lassen sich nutzen, um erste Pilotprojekte zu realisieren.

Stöger: Dass die Standards ausreichend definiert sind, um als technologische Basis dienen zu können, wurde besonders im letzten Jahr bereits bei den zahlreichen Plugfests im Rahmen des IIC-TSN-Testbeds erfolgreich demonstriert. Es gibt auch bereits TSN-IP-Implementierungen, die in verfügbaren Netzwerk-Produkten erhältlich sind. Allerdings muss man in den nächsten Jahren auf jeden Fall noch darauf achten, ob TSN-Ready-Geräte alle für den Anwendungsfall benötigten Eigenschaften und Features enthalten; erst mit breiter Marktdurchsetzung von TSN wird alles, was TSN zu bieten hat, auch wirklich überall darin enthalten sein, wo TSN draufsteht.

Wilmes: Wie erwähnt gibt es erste Chipsätze für einzelne Komponenten eines Anlagensystems. Für eine flächendeckende Implementierung in Steuerungen, Unterstationen, Schaltschränke sowie intelligente und weniger intelligente Ethernet-basierte Feldteilnehmer fehlen allerdings noch viele Chipsätze. Zudem sind die Standards für die Integration in die Software nicht abgeschlossen. Die Ethernet-Technologielieferanten haben die kurz- bis mittelfristige Verfügbarkeit zahlreicher Chipsätze angekündigt. Daher steht der aktuellen Entwicklung von Prototypen – zum Beispiel für die Beteiligung an einem Testbed – nichts entgegen, um Erfahrungen mit der neuen Technologie zu sammeln. Von einem herstellerübergreifenden interoperablen Serienstand ist die Automatisierung jedoch noch weit entfernt. Auf dieses Ziel arbeiten die wichtigsten Geräte- und Systemhersteller aber derzeit unter dem Gesichtspunkt des Kundennutzens und eigenen Wettbewerbsvorteils mit hoher Dynamik hin.

elektro AUTOMATION: Die Nutzung von TSN mit Profinet/Profisafe, Sercos, Powerlink, OPC UA, etc. setzt evtl. auch Engineering-Funktionalitäten bzw. Entwicklungstools voraus. Welche Unterstützung benötigt der Industrie-Anwender dafür zukünftig?

Beckmann: Die Konfiguration von TSN-Netzwerken ist die noch größte Unbekannte. In einem Interoperabilitäts-Workshop die verfügbaren Geräte verschiedener Hersteller so zu konfigurieren, dass sie in gewünschter Weise miteinander funktionieren, ist eine Sache. Eine generische Konfigurations-Schnittstelle sowie protokollunabhängige Optimierungsalgorithmen für die Datenströme in einem heterogenen TSN-Netzwerk zu standardisieren, ist dagegen eine weit größere, noch offene Herausforderung. Feldbus-Protokolle wie Ethercat ermöglichen heute eine einfache und automatische Konfiguration des Netzwerkes. Dies wird eine Messlatte für eine zukünftige TSN-Konfigurationsumgebung sein – herstellerunabhängig und über heterogene Protokolle hinweg.

Brandl: Auch bei der Kommunikation über OPC UA TSN wird der Anwender festlegen können, welche Daten zwischen Geräten ausgetauscht werden. Kunden von Rexroth werden das wie gewohnt in unserem Framework IndraWorks-Engineering tun. Unser Ziel ist es, dass dies keine speziellen Kenntnisse von Netzwerktechnologien erfordert und dem Ideal Plug-&-play möglichst nahe kommt. Damit dies auch herstellerübergreifend möglich ist, erarbeiten wir das Konzept für die Konfiguration der zukünftigen TSN-Kommunikationslösungen gemeinsam mit anderen Anbietern.

Hauser: Anwender werden hauptsächlich Tools zur Konfiguration und zum Monitoren und Debuggen der TSN-Netzwerke benötigen. Selbstverständlich kann die Konfiguration heute schon auf jedem Switch vorgenommen werden, allerdings ist das Verfahren etwas umständlich. Es gibt jedoch bereits prototypische Implementationen, die Konfiguration und Reservierung der TSN-Streams erleichtern und grafische Oberflächen bieten. Für das Monitoring und Debugging können Anwender herkömmliche Tools einsetzen, solange diese die spezifischen Punkte im TSN, wie etwa den Synchronisationsstatus, abdecken.

Jamal: OPC UA wird heutzutage bereits für die nicht-deterministische Kommunikation von Controller zu Controller eingesetzt. TSN verleiht solchen Installationen lediglich zusätzlich Echtzeitfunktionalität. Einige der heute existierenden Feldbusse können vielleicht über eine TSN-fähige Netzwerkinfrastruktur bedient werden. Daher erwarten wir eine evolutionäre Migration. Die heutigen Feldbusse werden Schritt für Schritt durch OPC UA over TSN erweitert. TSN ist komplett abwärtskompatibel mit jedem Ethernet-Gerät. Sprich, existierende Geräte werden ohne weitere Anpassung so funktionieren wie bisher. Wie erwähnt, liegt der Fokus der Avnu Alliance ja hauptsächlich auf Brownfield-Anwendungen. Während es eine Grundvoraussetzung ist, dass alle grundlegenden Elemente interoperabel sind, werden auch entsprechende Nachrüstungsmöglichkeiten für existierende Geräte in Betracht gezogen, sodass auch diese die Vorteile von TSN und seinen Installationen nutzen können. Hierzu gehören etwa Mechanismen wie die Kapselung von Applikationsprotokolldaten (Application Protocol Encapsulation), die Umwandlung des PTP-Profils (PTP profile conversion) und flexible Konfigurationsmechanismen. Mitglieder der Avnu Alliance zeigen bereits im IIC-Testbed einige dieser Elemente, wie etwa die Kapselung von Applikationsprotokolldaten und die Umwandlung des PTP-Profils. Bei den Nachrüstungsmöglichkeiten handelt es sich um Dienste existierender Geräte und Installationen, die in TSN-basierte Dienste und Protokolle umgewandelt werden müssen. Dies kann etwa ein Time Gateway zur Übertragung der Zeit sein, eine Remote Management Unit zur Übertragung existierender Konfigurationsprotokolle in Restconf oder Netconf oder ein TSN-Übertragungsmechanismus zur Umwandlung des asynchronen in synchronen Datenverkehr. Die Konformitätsprüfungen der Avnu Alliance werden solche Übertragungsfunktionen, die die Nutzung existierender Dienste unterstützen sollen, beinhalten.

Kleineberg: Dies hängt insbesondere davon ab, welche Topologien und Konfigurationsmechanismen zusätzlich zu den Mechanismen verwendet werden sollen, die das Industrieprotokoll auch ohne TSN unterstützt. Grundsätzlich muss sich das Engineering in Bezug auf die Fähigkeiten eines Industrieprotokolls nur dann ändern, wenn die Fähigkeiten des Protokolls selbst angepasst werden. Sollen neue Mechanismen für Scheduling oder neue Netzwerktopologien unterstützt werden, die TSN als Mehrwert über die Mechanismen des Industrieprotokoll hinaus bietet, so muss dies entweder im Engineering des jeweiligen Protokolls abgebildet oder ein dediziertes Konfigurationswerkzeug für TSN zusätzlich verwendet werden. Denn ohne Konfiguration kann der Mehrwert der meisten TSN-Funktionen nicht genutzt werden.

Lutz: Da die Vielfältigkeit von Ethernet-TSN mit den verschiedenen Substandards die Komplexität der Netzwerke erhöht, kommt den Themen Konfiguration und Diagnose eine ganz entscheidende Bedeutung zu. Die Konfiguration der TSN-Teilnehmer (Infrastrukturkomponenten und auch Endgeräte) kann zwar grundsätzlich manuell vorgenommen werden. Eine praxistaugliche Verwendung von TSN wird jedoch nicht ohne komfortable, benutzerfreundliche Konfigurations- und Diagnosewerkzeuge möglich sein, insbesondere wenn die Netzwerkinfrastruktur gemeinsam von verschiedenen Echtzeitprotokollen genutzt wird und viele Teilnehmer angeschlossen werden. Protokollspezifische Tools, wie der Sercos-Monitor als leistungsfähiges Diagnose- und Analysewerkzeug, können jedoch weiterhin in vollem Umfang verwendet werden.

Rostan: Die herstellerunabhängige Konfiguration von TSN-Geräten dürfte die größte Herausforderung bei der Anwendung von TSN werden. Innerhalb einer homogenen Infrastruktur mag das versteckbar und damit beherrschbar sein – also innerhalb eines abgeschlossenen Netzwerksegmentes mit einer einzigen Industrial-Ethernet-Ausprägung, oder wenn alle Geräte von einem Hersteller stammen. Aber damit würde ja ein Haupt-Ziel der TSN Technologien verfehlt: Determinismus in heterogenen Netzwerken, an die Steuerungen ebenso wie Kameras, Server und Drucker angeschlossen sind. Ich erwarte, dass sich an der Frage des Konfigurationsaufwandes entscheiden wird, wie erfolgreich TSN im Automatisierungsumfeld werden wird. Hier ist noch besonders viel zu tun.

Sachse: Die Nutzung von TSN in Kombination mit den heutigen Feldbussen halten wir für einen unnötigen Umweg und nur eine politische Zwischenstation auf dem Weg in die Zukunft – damit würde der Kunde wohl zweimal die Technologie wechseln müssen. Zukunftssicher ist aus unserer Sicht nur OPC UA TSN – nur diese Kombination verspricht echte Offenheit und eine durchgängige Industrial-IoT-Lösung. Engineering Tools werden bei der Netzwerkinbetriebnahme zukünftig eine viel größere Rolle spielen als heute. Das liegt nicht an den verwendeten Technologien, sondern an den rasant wachsenden Netzwerken mit hunderten von Knoten. Es wird daher entscheidend sein, dass Tools zur Verfügung stehen, mit denen auch große Netzwerke einfach konfiguriert werden können. Der Nutzer soll sich mit Themen wie Zeitsynchronisierung, Verkehrspriorisierung in Switchen oder Forwarding gar nicht auseinandersetzen müssen. Das ist das Ziel, auf das die Entwicklungen der Engineering Tools hinzielen.

Schneider: Die Entwicklung von Engineering-Tools ist nicht abgeschlossen. Allerdings schlägt sich PI hier auf die Seite der Anwender, die möglichst wenige oder am besten gar keine externen Konfigurationstools für die Integration von TSN wollen. Man darf nicht vergessen, die meisten Anlagen sind Bestandsanlagen und keine Neuplanungen. Und hier gibt es eine hohe installierte Basis von Profinet-Geräten. Die Anwendersicht auf z. B. I/O-Daten, Parametrierung, Diagnose, etc. soll sich daher auch bei der Integration von TSN nicht ändern. Daher setzt PI auf das Konfigurationsmodell der IEEE, mit dem sich flexible und leistungsfähige Anlagennetze erstellen lassen.

Stock: Die Konfiguration und der Betrieb eines TSN-Netzwerks müssen für den Anwender mindestens so einfach möglich sein, wie er es von bestehenden Lösungen gewohnt ist. Auf der anderen Seite kann die Komplexität der Konfiguration insbesondere zum Erreichen harter Echtzeit in einem verzweigten Netzwerk sehr hoch werden. Die Brücke müssen entsprechende Tools schlagen. Hier liegt heute die größte Herausforderung für die erfolgreiche Einführung der TSN-Technologie. Das Besondere ist, dass die Netzwerkkonfiguration systemübergreifend erfolgen muss. Die zukünftigen Engineering-Tools müssen mit der Netzwerkinfrastruktur interagieren, um die benötigten Kommunikationsbeziehungen sicherzustellen. Werkzeuge zur Diagnose sind wichtig, damit die Ursachen von Störungen in einem heterogenen TSN-Netzwerk effizient ermittelt werden können.

Stöger: TSN selbst ist als reine Netzwerkschicht für die Anwendung nicht relevant und soll – mittels der dafür vorgesehen Standards – quasi unsichtbar in die Engineering-Tools und Entwicklungsprozesse eingebettet werden. Die für herstellerunabhängige Interoperabilität notwendigen Konfigurations- bzw. Softwareschnittstellen sind in der TSN-Standardisierung enthalten. Wie gut oder wie ‚seamless‘ diese TSN-Konfigurationsmethoden dann tatsächlich in den Entwicklungstools integriert werden, hängt vom jeweiligen Anbieter ab. Auch hybride Netzwerke oder Gateways zwischen TSN- und anderen Automatisierungsnetzwerken können auf diese Art realisiert werden. Der Anwender selbst wird das Vorhandensein von TSN hauptsächlich daran merken, dass gewisse Zeiteigenschaften schon von der Konfiguration garantiert werden können und nicht erst durch Tests überprüft werden müssen.

Wilmes: Die Einfachheit der Handhabung ist ein Schlüsselfaktor für die erfolgreiche Einführung neuer Technologien. Dabei sind die Engineering-Tools über die gesamte Engineering-Kette zu betrachten. Es verschwimmen auch die Verantwortlichkeitsgrenzen in einem übergreifenden funktionalen Anlagenkontext. Neben der Steuerungsfunktion gibt es in diesem Netzwerk beispielsweise Big-Data-Analysefunktionen oder Asset-Management-Funktionen. Die Komplexität der Kombination dieser Funktionen darf sich allerdings nicht auf die Wartbarkeit, Testbarkeit oder Stabilität auswirken. Hier kommen zurzeit noch die größten weißen Flächen bei TSN auf, denn die geforderte Einfachheit steht leider in keiner Norm oder Profilbeschreibung.

Whitepaper – der aktuelle Stand

OPC UA TSN wird erstmals in der Geschichte der Feldbusentwicklung herstellerunabhängig von einer großen Zahl an Automatisierungs- und IT-Anbietern unterstützt – und von diesen als ‚Game Changer‘ im Feld der industriellen Automation angesehen. OPC UA TSN könne der erste und einzige Kandidat sein, um eine ganzheitliche Kommunikations-Infrastruktur vom Sensor bis zur Cloud zu realisieren. Erste Erfahrungen der beteiligten Unternehmen – B&R Industrial Automation, Schneider Electric, ABB Automation Products, TTTech Computertechnik, General Electric Company, Huawei Technologies, Fraunhofer IOSB-INA, Phoenix Contact Electronics, Intel Corporation, Bosch Rexroth, Cisco Systems, Hirschmann Automation and Control, Moxa und Kalycito Infotech – finden sich in einem Mitte Januar 2018 veröffentlichten Whitepaper, das über den folgenden Link zugänglich ist:

„TSN reduziert Ver- zögerungszeiten und gewährleistet eine Synchronisierung aller Teilnehmer – ersetzt aber keinesfalls den Echtzeitfeldbus.“

„Mit TSN wird die Performance von Echtzeit-Feldbussen ohne spezifische Erweiterungen des Ethernet-Standards erreicht.“

„TSN ist ideal für die Konvergenz von IT-

„TSN hat langfristig das Potenzial, klassische Feldbusse nach und nach zu verdrängen.“

„OPC UA, transportiert über TSN, ist eine leistungsfähige Gesamtlösung für eine herstellerneutrale Echtzeit-Kommunikation.“

„Die Verfügbarkeit von Standard-Ethernet-Komponenten mit integrierter Echtzeitfähigkeit macht spezielle Hardware-Implementierungen überflüssig.“

„TSN ist kein Feldbus und wird auch keiner werden – OPC UA übrigens auch nicht.“

„TSN in Kombination mit den heutigen Feldbussen halten wir für einen unnötigen Umweg und nur eine Zwischenstation auf dem Weg in die Zukunft.“

„TSN definiert lediglich einen Layer 2 für die Kommunikation, ist also nicht als Feldbusersatz zu sehen.“

„Konfiguration und Betrieb von TSN müssen für den Anwender so einfach sein, wie er es von bestehenden Lösungen gewohnt ist.“

„TSN skaliert bis in die Feldebene, weil es als Erweiterung von Ethernet die unterschiedlichen Bandbreiten und Topologien unterstützt.“

„Die geforderte Ein-fachheit steht leider

in keiner Norm oder Profilbeschreibung.“