Die Usability muss an oberster Stelle stehen, ansonsten hat TSN keine Chance. (Bild: Redaktion IEE)
Herr Schneider, 2017 begannen die Arbeiten an der Spezifikation Profinet over TSN, eingebettet in der Taskforce Industrie 4.0. Jetzt hat die Arbeitsgruppe geliefert, schon oder erst nach gut zwei Jahren?
Karsten Schneider: Bei den Arbeiten im Rahmen der Task Force haben sich viele Themen mit unterschiedlichsten Aspekten herauskristallisiert, die bei der Spezifikation zu berücksichtigen waren – nicht nur das Thema TSN als neuer Mechanismus für die Kommunikation. Die Semantik, also wie beschreibe ich Daten, wie mache ich Daten verfügbar für eine vertikale Kommunikation, solche Themen mussten von der Anforderungsseite her definiert werden, bevor wir sie an die einzelnen Technikarbeitsgruppen weiterleiten konnten.
Es ist ja auch nicht so, dass die PNO beim Thema TSN allein unterwegs wäre. Wir hängen von den Arbeiten in der IEEE ab und arbeiten auch mit anderen Organisationen zusammen, um das große Ziel zu erreichen – ein konvergentes Netzwerk. Wir können daher durchaus zufrieden sein mit dem Zeitplan.
Sind denn die IEEE-Standards alle fertig, die Profinet benötigt?
Ich bin mit unserem Zeitplan zufrieden. Redaktion IEE
Karsten Schneider: Um ehrlich zu sein, Jein. Die drei fundamentalen Specs für den eigentlichen Betrieb eines TSN-Netzwerks, die IEEE 802.1Q TAS, IEEE802.3 Preemption und IEEE 802.1AS Time&Takt Synchronisation, die sind durch. Das betrifft etwa, wie Datenstreams entsprechend ihrer Priorität und Latenzanforderungen im Switch weitergeleitet werden. Was noch nicht final feststeht, das ist der Aufbau eines Streams. Hier spielt auch das Thema Konfiguration rein und wie ein Stream im Netz etabliert wird. Das muss noch definiert und verabschiedet werden.
Bis wann soll das erledigt sein, gibt es dazu eine Timeline?
Karsten Schneider: Die IEEE 60802 TSN Profile for Industrial Automation soll bis 2021 fertig sein. Aber es ist ein wichtiger Baustein, der einfach noch gelöst werden muss.
Ginge auch ohne diesen Baustein eine Implementierung?
Karsten Schneider: Natürlich kann und sollte man sich jetzt schon mit der Implementierung beschäftigen. Bis eine komplette Anlage allein mit TSN als Kommunikationsbackbone realisiert werden kann, dauert das noch. Zum einen fehlen die fertigen Produkte und zum anderen die Definitionen zum Aufbau und Strukturierung des Netzes. Wir müssen an der Stelle noch abwarten, nicht, dass am Ende die Interoperabilität auf der Strecke bleibt.
Es kann also noch Wechselwirkungen geben. Macht es unter der Prämisse Sinn, die PNO-Spezifikation für TSN schon jetzt in Software zu gießen?
Auf unserem TSN Demonstrator zeigen wir auch dieses Jahr auf der SPS wieder einige Implementierungen. Redaktion IEE
Karsten Schneider: Die Spezifikation ist fertig und dient als Grundlage für Prototypen, unter anderem auch für unsere Messedemo auf der SPS. Auch die Demoanlagen auf der Hannover Messe basierte auf dem damaligen Spezifikationsstand. Bereits damals konnten mehrere Hersteller die Interoperabilität belegen. Für uns sind die Demos ein begleitender Proof of Concept. Was wir jetzt angehen ist, das Zertifizierungswesen zu entwickeln. Nur dann kann es auch wirklich Produkte geben.
Werden die Test-Spezifikationen auch im Laufe von 2020 fertig?
Karsten Schneider: Erste Schritte werden nun getan. Die notwendigen Vorarbeiten ‒ ein Testsystem, das mit der TSN-Hardware zurechtkommt, ist verfügbar. Das ist notwendig, da bei TSN Themen wie Zeitsynchronisierung und Deterministik eine Rolle spielen. Dafür braucht es eine spezielle Hardware, mit der sich Geschwindigkeit und Performance der TSN-Geräte auch prüfen lassen. Aktuell arbeiten wir an der Umsetzung der Test-Cases, so dass wir nächstes Jahr ein entsprechendes Testsystem auf der Hannover Messe vorstellen können.
Rechnen Sie zur SPS schon mit ersten Implementierungen?
Karsten Schneider: Die üblichen Verdächtigen waren und sind bei unseren Demonstratoren und vor allem bei der Entwicklung und dem Review der Spezifikation mit dabei. Sie beschäftigen sich schon seit Jahren intensiv mit der Materie und sind technologisch auf Ballhöhe. Auf unserem TSN Demonstrator zeigen wir auch dieses Jahr auf der SPS wieder einige Implementierungen.
Sie erwähnten, dass der Aufbau eines TSN-Streams noch nicht festgezurrt sei. Wie sieht es mit dem Thema Administration/Konfiguration eines TSN-Netzwerks aus? Von Anfang an scheiden sich die Geister hier in zentral oder dezentral.
Karsten Schneider: Beide Verfahren haben ihre Berechtigung und werden auch verfügbar sein. Denn am Ende zählt die Usability – und die hängt vom Anwendungsfall ab. Wer TSN als Next Generation Feldbus oder als neues Profinet sieht, der will weiterhin so konfigurieren wie er es von Profinet her kennt, eventuell mit etwas besserer Usability. Diese Anwendergruppe möchte in diesem Duktus bleiben und einfach die IO-Geräte der jeweiligen Steuerung zuordnen. Den Rest erledigt das System automatisch.
Zentral, dezentral – beide Konfigurationsarten sind notwendig . Redaktion IEE
Und das dezentrale Szenario?
Karsten Schneider: Wer Aggregate in seine Anlage einbinden will, seine Produktionslinie on the Fly ändern will, braucht Flexibilität. Ein zentraler Ansatz behindert das. Es braucht daher beide Varianten. Deswegen sind die noch ausstehenden IEEE-Standards zur Einrichtung der TSN-Datenstreams wichtig. Über diese Definitionen lassen sich beide Konfigurations-Verfahren zusammenführen. Dann ist es egal, ob der Usecase zentral oder dezentral gelöst wird. Die TSN-Geräte können mit beidem umgehen.
Wird auch das Aussehen der Administrationstools definiert?
Karsten Schneider: Es braucht kein einheitliches GUI, sondern eine Art API. Darüber müssen sich verschiedene Softwaretools und Geräte mit dem Netz unterhalten und beispielsweise Streams anmelden können. Die Konzeption der Schnittstelle erfolgt in der IEEE 60802. Daraus leiten sich wiederum weitere Standardisierungsaktivitäten innerhalb von IEEE und IEC ab.
Und das Thema Performancesteigerung spielt bei Profinet over TSN keine Rolle mehr, um die IRT-Latenz in der Breite auszurollen?
Karsten Schneider: Die Performance ist nicht mehr das Thema, die Bandbreite zählt, um die Dienste von Industrie 4.0 und IoT bedienen zu können. Die Namur Open Architecture NOA ist ein gutes Beispiel dafür. Deren Kerngedanke ist, für die vertikale Kommunikation einen Kanal bereitzustellen, über den sich rückwirkungsfrei Informationen aus den Geräten abrufen lassen. Das hat mit der eigentlichen Steuerungsaufgabe gar nichts zu tun, ist also ein zusätzlicher Dienst.
Bei IRT haben wir das bereits mit dem reservierten Kanal umgesetzt. Jetzt setzen wir das Konzept mit Profinet over TSN auf einem globalen Standard auf.
Wie sieht denn die Migrationsstrategie aus ihrer Sicht für einen Maschinenbauer aus, der Profinet RT und IRT in der Anlage installiert hat. Braucht er zwingend ein Gateway oder kann er einen gemischten Betrieb fahren?
Karsten Schneider: Das Thema Migration war für uns ein wichtiger Aspekt. Wir haben die Applikationsschicht deshalb gleich gelassen. Aus der Automatisierungsperspektive arbeitet der Projekteur daher mit denselben Profilen und identischer Handhabung. Dadurch gibt es hinsichtlich der gesamten Applikationsprogrammierung keinen Unterschied.
Um TSN zu unterstützen, braucht es natürlich Geräte mit der entsprechenden Hardware. Weil TSN nach wie vor Standard Ethernet ist, können natürlich auch RT-Geräte an eine TSN-Domain angeschlossen werden. Für IRT-Geräte braucht es wie bisher auch einen Übergang von TSN zu IRT.
In der Ankündigung zur fertigen TSN-Spezifikation heißt es „die TSN-Mechanismen betreffen im Wesentlichen nur den Layer 2.“ Umkehrschluss: Es bleibt nicht nur auf den Layer 2 beschränkt. Hat das Auswirkungen auf die ursprüngliche Zielsetzung, applikationsneutral zu bleiben?
Die Nach-Feldbus-Generation muss viel mehr können als die heutigen Feldbusse, und damit meine ich jetzt nicht nur Profibus oder Profinet, ich meine alle Feldbusse. Redaktion IEE
Karsten Schneider: Da muss man unterscheiden. Aus Sicht der Applikation eines Automatisierers, der mit seiner Engineering Software eine Steuerung programmiert, ist es identisch. Er muss nichts am Engineering ändern. Natürlich braucht TSN eine Konfiguration, die erstellt werden muss. Das übernimmt bei uns die Network Management Engine. Diese Engine ist in der Steuerung installiert und sorgt etwa dafür, dass die TSN-Konfigurationsdaten an die Geräte geschickt werden. Nur der Steuerungshersteller muss sich mit dem Thema beschäftigen und die Network Management Engine integrieren.
Diese Engine berechnet oder simuliert praktisch die Netzlast und schlägt Alarm, wenn das Netzwerk die Anforderungen eines Geräts an Reaktionszeiten oder Bandbreite nicht mehr einhalten kann?
Karsten Schneider: So kann man sich das vorstellen.
Wie funktioniert das bei modularen Anlagenkonzepten, bei denen sich etwa FTS an- und abmelden.
Karsten Schneider: Probleme können immer auftreten, wenn mehr Daten durchs Netz geschickt werden sollen, als das Netz an Bandbreite zur Verfügung stellen kann. Hier bietet uns die TSN-Technologie Möglichkeiten, das einerseits im Vorfeld schon im Engineeringsystem zu simulieren, Engpässe zu erkennen und an den kritischen Stellen gegenzusteuern.
Gerade bei modularen Anlagendesigns ist das Thema Sicherheitstechnik, das Verketten von Sicherheitskreisen wichtig. Profisafe bietet diese Funktionalität, künftig auch über TSN?
Karsten Schneider: Das ist das Schöne. Die Applikationsschicht in unserer Spezifikation bleibt unangetastet. Also nicht nur Profisafe, sondern alle anderen Applikationsprofile funktionieren auf TSN ganz genau so wie auf Profinet RT oder IRT.
Und wie sieht es mit der Controller-zu-Controller-Kommunikation aus, für die aktuell OPC UA genutzt wird?
Karsten Schneider: Es macht auch bei TSN Sinn, die Kommunikation zwischen Controllern per OPC zu lösen, auch was das Thema vertikale Kommunikation betrifft. OPC hat hier den Vorteil, dass man zusammen mit den Daten die Semantik oder eine Selbstbeschreibung übertragen kann. Deswegen passen OPC und TSN perfekt zusammen. Mit TSN lassen sich die unterschiedlichen Aufgaben über die Streams sauber trennen. Und die höhere Bandbreite erlaubt mir, diese Dienste gleichzeitig über dasselbe Netz zu realisieren.
Kritisieren Sie gerade die Aktivitäten der OPC Foundation in Richtung Field Level Communications?
Karsten Schneider: Jein. Zu kritisieren wäre es, wenn die OPC Arbeitsgruppe FLC nur einen neuen Feldbus bauen würde. Das wäre viel zu kurz gesprungen. Wenn man die Hindernisse und Beschränkungen der heutigen Feldbusse beseitigt, dann macht das Sinn. Ich denke hier etwa an Themen wie Semantik, automatische Konfiguration und ähnliche Dinge. Das muss meiner Meinung nach auch das Ziel der FLC-Initiative sein – die Definition der industriellen Kommunikation nach den Feldbussen.
Und Profinet over TSN erfüllt nicht die Kriterien eines Next Generation Fieldbus?
Karsten Schneider: Jein. Profinet over TSN ist neben Profinet RT und IRT ein weiterer Mechanismus, wie Profinet-Telegramme übertragen werden. Ich könnte anstatt TSN auch Wireless und 5G als Transportmedium nennen. Denn am Protokoll Profinet ändert sich dadurch ja nichts. Deswegen kann man das nur bedingt als nächste Feldbusgeneration bezeichnen. Für uns als PNO ist es natürlich die nächste Generation.
Die Nach-Feldbus-Generation muss viel mehr können als die heutigen Feldbusse, und damit meine ich jetzt nicht nur Profibus oder Profinet, ich meine alle Feldbusse.
Welche Rolle kann/wird 5G spielen?
Karsten Schneider: 5G bringt einen neuen Aspekt, weil sich damit Dinge realisieren lassen, die drahtlos in der Form heute nicht zu lösen sind. Aber auch hier sind wie bei TSN noch wichtige Randbedingungen zu erfüllen.
Welche denn?
Karsten Schneider: Wir brauchen dringend den Release 16 beziehungsweise 17, bevor wir 5G industriell signifikant nutzen können. Denn die regeln Eigenschaften wie die Latenzzeiten.
Wie wirkt sich TSN als gemeinsamer Layer 2 auf die Kooperationen aus, etwa mit der CC-Link-Organisation.
Karsten Schneider: Ich gehe davon aus, dass wir uns mit der IEC 60802 auf ein einheitliches TSN einigen. Somit haben wir in Zukunft die Möglichkeit, verschiedenste Protokolle über ein Netzwerk zu senden. Es sind und bleiben aber unterschiedliche Protokolle. Hier sehe ich eine wichtige Funktion von OPC UA, diese Machine-to-Machine-Kommunikation herzustellen. Das war ja auch der ursprüngliche Usecase der Kooperation mit der CLPA. Das würde ich künftig mit OPC auf Basis von TSN lösen.
TSN ist ja ein reines Kommunikationsthema auf dem Netzwerk. Spannender ist das Thema Semantik. Wer im Rahmen von IIoT hunderte oder tausende Sensoren an die Cloud anschließen will, muss das automatisiert erledigen können. Von Hand wie bisher ist das nicht mehr zu stemmen. Dafür braucht es einheitliche Informationsmodelle, mit denen die Experten aus der Steuerungswelt wie auch die der Cloud-Anbieter arbeiten können. Und diese Welten miteinander zu verbinden, da kann die PNO einen großen Beitrag leisten. Zusammen mit der OPC Foundation können daraus Companion Specs entstehen, die von einer breiten Masse getragen werden.
Vom VDMA und VDW gibt es schon solche Informationsmodelle.
Karsten Schneider: Ein VDMA kann das sehr gut für seine Welt der Maschinen definieren. Wir können es für die Gerätewelt.
Das Interview führte Chefredakteur Stefan Kuppinger
PNO auf der SPS 2019: Halle5, Stand 210
