Die Konvergenz von IT- und OT-Systemen ist ein zentraler Enabler der Digitalisierung der Produktion. Dabei werden die gleichen Hardware- und Softwarelösungen genutzt, eine Durchgängigkeit der Systeme angestrebt sowie Methoden und Tools übernommen. Darüber hinaus spielt auch der Infrastrukturgedanke aus der IT zunehmend eine Rolle: Lösungen werden nicht mehr als geschlossene Hardware-Software-Systeme realisiert, sondern soweit möglich digital auf einer gemeinsamen Infrastruktur umgesetzt, welche anwendungsabhängig durch zusätzliche Hardwarekomponenten ergänzt wird. Zentrale Komponenten dieser Infrastruktur sind das Netzwerk und Compute-Ressourcen, wie in Bild 1 schematisch dargestellt. Der Grad der Konvergenz kann stark variieren: Vom einfachen Zugriff auf Daten, beispielweise zum Tracking, bis hin zur Nutzung einer gemeinsamen IT-/OT-Infrastruktur für verteilte Echtzeitapplikationen virtualisierter Steuerungen. Letztere haben in jüngster Vergangenheit insbesondere in Form von virtualisierten SPS-Steuerungen (vPLC) an Popularität gewonnen.

Die Gründe hierfür sind vielfältig: erlaubt sie doch eine Konsolidierung vieler Steuerungen auf einer einzelnen Plattform anstelle einer großen Anzahl verteilter Geräte im Feld, aber auch Vorteile wie eine zentrale Wartbarkeit und Überwachung, Redundanz und Ausfallsicherheit, sowie insbesondere auch die vollständige Verfügbarkeit aller internen Steuerungsinformationen auf einem IT System, beispielsweise für Digitale Zwillinge oder KI-Anwendungen.

Eine zentrale Herausforderung für vPLCs ist neben der Konsolidierung von Echtzeit-Workloads die Anbindung der Feldebene. Hierfür sind konvergente Echtzeitnetzwerke nötig, für welche Time-Sensitive Networking (TSN), die Erweiterung der Ethernet-Standards um deterministische Funktionen, branchenübergreifend als Enabler anerkannt ist. TSN kann jedoch stets nur ein Teil der Lösung sein, da dieses lediglich die unteren Ebenen der Kommunikation abdeckt.

Feldkommunikation im Kontext von TSN

Bild 1. Die Infrastruktur der Fabrik der Zukunft.

© ISW

Feldgeräte sind heute typischerweise durch Feldbusse angebunden, welche sich in Ethernet-basierte und solche mit einer eigenen Übertragungsschicht einteilen lassen. Für die letzteren gibt es jedoch eine Vielzahl an Adaptern und Brücken, um sie in Ethernet-basierte Feldbusse einbinden zu können. Da die meisten Ethernet-basierten Feldbusse zwar viele Aspekte und Hardware von Ethernet verwenden, jedoch zur Erreichung der Echtzeitfähigkeit vom Standard abweichen, ist eine direkte Kompatibilität mit einem Standard-Ethernet-Netzwerk nicht gegeben.

Diese Aussage gilt es im Kontext von TSN jedoch neu zu bewerten. Zwar ändert sich am grundlegenden Kompatibilitätsproblem nichts, jedoch kann TSN dank deterministischer Funktionen durchaus interoperabel mit verschiedenen Feldbussen konfiguriert werden – und das völlig transparent für den Feldbus. Für Feldbusse wie Profinet oder EtherCAT ist hierfür eine dedizierte Betrachtung notwendig.

Mit der zunehmenden Bedeutung von TSN haben die Feldbusorganisationen verschiedene Ansätze veröffentlicht, wie sich TSN für die unteren Schichten standardkonform nutzen lässt, beispielweise mittels CC-Link IE TSN oder der Spezifikation von TSN als neue Conformance-Class für Profinet.

Hierbei gibt es zwei grundlegende Möglichkeiten zur Nutzung von TSN: Entweder lässt sich TSN als technologischer Baustein in einer eigenen Lösung nutzen. Hierbei werden die benötigten Features in einer spezifischen Konfiguration für das gesamte Kommunikationssystem bestehend aus Endgeräten, Infrastruktur und Management genutzt. Großer Vorteil ist die Unabhängigkeit von externen Systemen und weiteren Entwicklungen und somit eine umgehende Nutzbarkeit, weshalb diese Variante bei CC-Link IE TSN und Profinet gewählt wurde. Als signifikanter Nachteil ergibt sich eine nur sehr eingeschränkte Interoperabilität mit anderen Lösungen, beispielweise für den Best-Effort-Datenverkehr.

Der zweite grundlegende Ansatz zur Nutzung von TSN ist die Betrachtung des Netzwerks als Ressource: Anwendungen können Teile davon nach Bedarf mittels eines Managements allokieren, beispielweise Streams oder Bandbreitenreservierungen. Dies ermöglicht die Koexistenz vieler Echtzeitanwendungen, stellt aber wesentlich höhere Anforderungen an die Interoperabilität, das Management und das Engineering.

OPC UA FX, der in Standardisierung befindliche Ansatz, OPC UA bis hin zur Feldebene zu nutzen, setzt auf dieses Ressourcenmodell. Dementsprechend sind mit dieser Technologie viele Hoffnungen für eine interoperable Umsetzung der Vision vom Sensor bis zur Cloud verbunden.

Ebenfalls darauf basiert der von der EtherCAT Technology Group präsentierte Ansatz, wie EtherCAT in Kombination mit TSN genutzt werden kann, welches allerdings eine Sonderrolle spielt. Anders als bei Profinet oder CC-Link IE TSN wird TSN in diesem Fall nicht bis zum Feldgerät gesprochen, sondern lediglich EtherCAT Segmente über ein TSN-Netzwerk gekoppelt. Für diese Verbindung werden die EtherCAT Daten auf TSN Streams adaptiert, wofür spezielle Funktionen am Übergang notwendig sind, beispielweise im ersten Feldgerät oder einem speziellen Switch. Wie die TSN-Streams konkret im Netzwerk gemanagt werden ist außerhalb des Scopes der ETG, jedoch lässt sich hier problemlos ein ressourcenbasierter Ansatz wählen. Zusammengefasst gibt es mindestens drei grundlegende Möglichkeiten, wie sich TSN für die Feldkommunikation nutzen lässt, welche jedoch nur eingeschränkt zueinander interoperabel sind.

TSN-Backbone für die Fabrik

Das Netzwerk einer konvergenten Infrastruktur für die Fabrik der Zukunft setzt sich aus einem allgemeinen IT- und einem deterministischen Teil zusammen. Letzterer basiert auf TSN und sieht sich mit den oben genannten Interoperabilitätsproblemen konfrontiert. Langfristig ist eine ressourcenbasierte Lösung bis in alle Teilsysteme hinein erstrebenswert. Momentan ist dies auf Grund noch fehlender Standards und Tools nicht realistisch und effizient möglich. Zusätzlich werden die beschriebenen Kommunikationsansätze zumindest für den Zeitraum der typischen Lebenszyklen von Maschinen präsent sein. Für den TSN-Backbone ist daher einerseits zu klären wie dieser grundlegend spezifiziert werden sollte, um langfristig den Anforderungen zu genügen. Andererseits sollte es der Backbone ermöglichen, die bereits verfügbaren Ansätze und Lösungen möglichst umgehend nutzen zu können, um von der Konvergenz zu profitieren und virtuelle Steuerungen skalierbar einsetzbar zu machen.

Die zentralen Anforderungen lassen sich an den TSN-Backbone formulieren:

• Anwendungsunabhängigkeit: Verschiedene Anwendungen müssen parallel den Backbone nutzen können und hierzu auch verschiedene TSN-Funktionen einsetzen können, beispielweise Streams oder reservierte Bandbreiten.
• Parallele, gleichberechtigte Echtzeitapplikationen: Verschiedene Echtzeitdaten, beispielweise von vPLCs, müssen ohne Interferenz übertragbar sein. Es darf daher keine anwendungsübergreifenden Konflikte bei Priorisierung oder Preemption geben.
• Management: Der Backbone muss ohne notwendige tiefe Kenntnisse über ihn nutzbar sein. Den Nutzern müssen geeignete Schnittstellen zur Verfügung stehen, sowohl technische als auch organisatorische.

Feldkommunikation über den TSN-Backbone

Die effiziente und zeitnahe Nutzung des TSN-Backbones erfordert Lösungen für die Interoperabilität. In vielen Diskussionen herrscht die Meinung vor, dass sich die verschiedenen Ansätze nicht gemeinsam nutzen lassen. Ein weiteres Argument lautet oft: TSN sei erst sinnvoll nutzbar, wenn die Konfigurationsthematik vollständig gelöst sei und dass dies erst in vielen Jahren der Fall wäre. Um eine maximale Netzauslastung und das theoretische Optimum hinsichtlich Latenzen und Jitter zu erreichen, ist diese Argumentation sicher zutreffend. In Anbetracht der Tatsache aber, dass hauptsächlich isolierte 100-Mbit-Netzwerke mit einer Auslastung von unter 10 % im industriellen Umfeld zum Einsatz kommen, stellt sich die Frage: Ist ein konvergentes GBit-Netzwerk mit einem zweistelligen Auslastungsgrad nicht bereits ein erstrebenswerter Fortschritt und Mehrwert?

Bild 2. Der transparente Kanal durch ein TSN Netzwerk.

© ISW

Unter dieser Annahme und einer genauen Analyse der einzelnen Technologien lassen sich verschiedene pragmatische Ansätze nutzen. Ansätze, die sich bereits realisieren und nutzen lassen: Um die Gruppe der klassischen Ethernet-basierten Feldbusse durch ein TSN-Netzwerk zu tunneln, bietet sich ein transparenter Ansatz an. Die Grundidee ist, das Netzwerk so zu konfigurieren, dass sich die TSN-Strecke wie ein langes, aber deterministisches Kabel verhält. Hierzu kann eine Kombination aus logischer und zeitlicher Trennung mittels VLANs und Zeitslots oder Streams genutzt werden. Je nach Anforderungen des Feldbusses kann der so etablierte Kommunikationskanal asynchron – potenziell aber höherfrequent – zum Feldbus oder synchronisiert erfolgen. Zur Synchronisation kann ein Software-basierter Master mittels lokalem Applikations-Scheduling auf die TSN-Zeit synchronisiert werden, Traffic vor einem Feldbussegment lässt sich mittels geplantem Queuing und Qbv-Zeitslots mit einer Genauigkeit von rund 20 ns in ein Feldbussegment einbringen (Bild 2). Um die TSN-basierten Feldbusse in den Backbone zu integrieren, gilt es zu betrachten, welche Daten eine konkrete Applikation tatsächlich kommuniziert und welche Anforderungen an die Datenströme gelten. Mit dem Applikationswissen kann der relevante Teil des Feldbus-over-TSN-Netzwerks logisch und zeitlich in den Backbone einsortiert werden. Die Integration der Stream-basierten Ansätze, kann durch die dedizierte Planung der Streams erfolgen.