Viele Hersteller, Konsortien und TSN-Testbeds stellen ­TSN-Demonstratoren aus, die Anwendungen dieser Technologie mit bereits verfügbaren Komponenten zeigen. Renesas zum Beispiel zeigt heute schon eine Profinet-SPS mit IO-Link-Master-Anbindung über TSN basierend auf einem aktuellen Chip. Je nach den zu erfüllenden Anforderungen ist die Umsetzung solcher TSN-basierter Lösungen auf Grundlage verfügbarer Hardware relativ einfach möglich. So lassen sich Protokolle wie Profinet oder Ethernet/IP lediglich durch entsprechende Erweiterung des Ethernet Layer 2 und ohne ­Eingriffe in die höheren Protokollschichten durchaus TSN-fähig machen. Hier stellt die zeitgesteuerte Übertragung – ­Scheduled Traffic – die gängige Methode dar, weil dieser ­Mechanismus schon hinreichend in der Industrieautomatisierung erprobt und verbreitet ist. Bekannte Systeme wie Ethercat, Profinet IRT oder Sercos III setzen dieses Verfahren bereits seit Jahren erfolgreich ein.   

Doch im Portfolio der Automatisierer sind TSN-basierte Lösungen noch nicht wirklich angekommen. Der Grund hierfür liegt in der momentanen Diskrepanz zwischen den eigentlichen Zielen der TSN-Einführung und dem bis dato erreichten.

Die Ziele der TSN-Einführung

Bild 1: Die Automatisierungspyramide und die Daten-Durchgängigkeit

© Renesas

TSN ist ein wichtiger Baustein zur Erfüllung der für die Industrie 4.0 gesetzten Ziele. Die Technologie hat das Potenzial, die Grenzen, die momentan zwischen den verschiedenen proprietären Echtzeit-Lösungen bestehen, durch einen vereinheitlichten Standard aufzuheben. Damit wird der Datenaustausch innerhalb einzelner Bestandteile einer Produktionsstätte einfacher und transparenter. Verschiedene Bereiche der Anlage können über eine einheitliche Netzwerk-Infrastruktur direkt miteinander Informationen austauschen, ohne dass Gateways oder anderweitige Anpassungen notwendig wären. Als Beispiel können Maschinen unterschiedlicher Hersteller flexibel zu Produktionsstraßen kombiniert oder zwischen verschiedenen Bereichen ausgetauscht werden, ohne auf einen jeweils verwendeten, heute noch inkompatiblen Kommunikationsstandard Rücksicht nehmen zu müssen. Außerdem lässt sich so die vollständige Durchgängigkeit des Informationsflusses in vertikaler Richtung realisieren, Stichwort ‚Sensor to the Cloud‘, wodurch neue Geschäftsmodelle möglich werden.

Ein weiteres Ziel ist die Standardisierung der Automatisierungsgeräte und ihrer Bestandteile, wodurch sich die Kosten für deren Entwicklung, Herstellung und Ersatzteilbevorratung sowie in der Wartung der Produktionsstätte senken lassen. Fachpersonal in Konstruktion und Instandhaltung wird flexibler einsetzbar, Lagerhaltung für Ersatzteile beschränkt sich auf einen Gerätetyp und vereinheitlichte Hardware-Komponenten werden in den daraus folgenden höheren Stückzahlen preisgünstiger.

Die Voraussetzungen

Dieses abstrakte Ziel lässt mehrere Lösungswege zu, die sich insbesondere in der untersten Ebene der Automatisierungspyramide unterscheiden. Grundsätzlich können wir zwischen Koexistenz und Interoperabilität unterscheiden. Koexistenz oder auch Konvergenz bedeutet, dass Geräte sich ein gemeinsames Netzwerk-Segment teilen und darüber kommunizieren können, ohne dass sie sich gegenseitig beeinträchtigen. Interoperabilität bedeutet darüber hinaus, dass sich die Geräte auch untereinander ‚verstehen‘, das heißt miteinander Informationen austauschen können. Die heute verfügbaren echtzeitfähigen Netzwerke sind überwiegend weder koexistent noch interoperabel zueinander. TSN als einheitlicher Netzwerk-Standard kann die Forderung nach Koexistenz erfüllen. Die IEEE entwickelt allerdings nur horizontale Netzwerk-Standards, die Basisfunktionen beschreiben. Beispielsweise sind zum ‚Scheduled Traffic‘ (IEEE 802.1Qbv-2015, jetzt in IEEE 802.1Q-2018 übernommen) nur Prinzip und Mechanismen festgelegt, über die sich Sendezeitpunkte der Ethernet-Pakete steuern lassen. Eine konkrete Anwendung erfordert jedoch spezifische Festlegungen wie: die Zykluszeit, die konkrete Abfolge der Zeitintervalle, die Definition und Behandlung der Prioritätsklassen, die Art und Weise der Netzwerk-Verwaltung. Dies stellt dann das anwendungsspezifische Profil oder den vertikalen Standard dar.

Bild 2: Horizontale und vertikale Standards

© Renesas

Ohne diese Übereinkunft würden verschiedene Geräte, die die TSN-Mechanismen unterschiedlich anwenden, trotzdem keine Koexistenz in einem heterogenen Netzwerk ermöglichen. Als Konsequenz würde eine erneute Zersplitterung der TSN-basierten Netzwerke folgen. Selbst die Nutzung gleicher Halbleiterchips wäre in diesem Fall eventuell ineffizient, falls sich die Hardware-Anforderungen der Profile zu sehr unterscheiden sollten.

Seit diesem Jahr kümmert sich eine gemeinsame Arbeitsgruppe IEEE/IEC 60802 um die angesprochene Problematik. Sie hat den Arbeitsauftrag, ein einheitliches TSN-Profil für industrielle Ethernet-Anwendungen zu definieren und dabei auftretende Lücken in den IEEE-Spezifikationen zu schließen. Der Erfolg dieser Arbeitsgruppe, zu der viele Experten und Konsortien Beiträge liefern, wird die Konvergenz zukünftiger industrieller TSN-Anwendungen einen entscheidenden Schritt voranbringen. Das Profil soll im Jahr 2021 verabschiedet werden.

Der zweite Aspekt der Industrie-4.0-Ziele betrifft die Interoperabilität von Automatisierungsgeräten. Hierzu ist zusätzlich zur Koexistenz im gleichen Netzwerk eine gemeinsame Sprache und eine gleichartige Verwaltung und Planung der Automatisierungsanwendung (Engineering) erforderlich. Die gemeinsame Sprache ist bereits gefunden. Es handelt sich um OPC UA Pub/Sub, die echtzeitfähige Erweiterung des etablierten OPC-UA-Standards. Auf der SPS IPC Drives 2018 wurde eine neue Initiative zur Definition eines einheitlichen OPC-UA- Pub/Sub-basierten Feldbus-Standards unter dem Dach der OPC-Foundation bekannt gegeben, an der sich analog zur IEEE/IEC 60802 sämtliche namhaften Hersteller beteiligen.
OPC UA Pub/Sub ermöglicht Echtzeit-Kommunikation auf dem Niveau etablierter Protokolle mit Zykluszeiten unter 1 ms wie beispielsweise Profinet oder Ethernet/IP. OPC UA Pub/Sub verwendet Multicast-Frames, die ein Publisher zyklisch an einen oder mehrere Subscriber verschickt. Damit ist die Vernetzung bis hinab auf die Maschinenebene (Controller zu Controller) lösbar.

Verfügbare Chip-Bausteine

© Renesas

TSN bietet generell zwei wesentliche Methoden für die deterministische Übertragung der Daten an:

• die Priorisierung und Frame Preemption für asynchrone Übertragung 
• die synchrone, zeitgesteuerte Übertragung in reservierten Zeitfenstern (TDMA-Verfahren). 

Harte Echtzeit über TSN – In der Industrieautomatisierung geschieht dies nach IEEE 802.1Qbv. Diese Norm vermeidet unerwünschte Kollisionen zwischen unterschiedlichen Datenströmen. Auch die etablierten Verfahren nach IEEE 1588 beziehungsweise IEEE 802.1AS stellen dieselben Anforderungen an die Hardware wie die IEEE 802.1Qbv. Entsprechende Bausteine müssen über einen PTP-Hardwaretimer verfügen, von dem Zeitstempel beim Senden und Empfangen der Zeitsynchronisationsnachrichten abgeleitet werden. Frequenz und Phase des PTP-Timers müssen sich durch die Zeitsynchronisation nachregeln lassen.

Der heute verfügbare RZ/N1-Baustein von Renesas Electronics bietet bereits Mechanismen wie die hochgenaue Zeitsynchronisation sowie zeitgesteuerte Übertragung im TDMA-Verfahren:

• Die Unterstützung für IEEE 1588: Für TSN ist das neue IEEE-802.1AS-Rev-Protokoll vorgesehen, das auf IEEE 1588 basiert und keine zusätzlichen Ansprüche an die Hardware stellt. Heute wird alternativ sein Vorläufer IEEE 802.1AS oder das bisherige IEEE 1588 eingesetzt. Die Unterschiede in der Umsetzung der beiden liegen ausschließlich in den Software-Schichten.
• Die Unterstützung für das TDMA-Verfahren: Das TDMA-Verfahren ist als Erweiterung der Qav-Spezifikation ebenfalls schon in verfügbaren Chips umgesetzt. Hierbei wird die Klassifikation der Ethernet-Frames nach Qav verwendet, um sie einzelnen Zeitschlitzen innerhalb eines Übertragungszyklus zuzuordnen. Dieser Mechanismus ist der Vorläufer des TSN-Substandards Qbv. Ein Chip mit 1588/.1AS-Unterstützung und Qav+TDMA ist geeignet, um eine vereinfachte Qbv-TSN-Funktionalität zu realisieren. Die Unterschiede zu einer Qbv-fähigen Hardware bestehen hauptsächlich in der Anzahl unterschiedlicher Queues und Zeitschlitze.

Darüber hinaus eignet sich die RZ/N-Serie zum Einsatz in industriellen Netzwerk-Geräten. Sie ermöglicht Skalierbarkeit mit drei Produktgruppen: 

• Die RZ/N1D-Gruppe für High-End-Anwendungen wie speicherprogrammierbare Steuerungen (SPS) oder Bediener-Terminals. Eine Dual Core Arm® Cortex-A7 steuert die Anwendungssoftware, während eine Arm Cortex-M3 über eine R-IN-Engine-Architektur verfügt und die Industrial-Ethernet-Kommunikation unterstützt. 
• Die RZ/N1S-Gruppe für Midrange-Anwendungen wie Gateways oder Remote-I/O-Einheiten mit einem Arm-Cortex-A7-Applikationsprozessor, einem Arm-Cortex-M3-Kommunikationsprozessor und einem relativ großen integrierten SRAM. 
• Die RZ/N1L-Gruppe mit einem Arm-Cortex-M3-Kommunikationsprozessor, die eine einfache Multiprotokoll-Konnektivität anbietet.

Die universelle Kommunikations-API bietet eine gemeinsame Software-Infrastruktur für die wichtigsten industriellen Netzwerk-Protokolle und beschleunigt die Anwendungsentwicklung. Systementwickler können bei Bedarf einfach und mit nur minimalen Auswirkungen auf die Anwendungssoftware zwischen den Protokollen wechseln. Neben Linux können Entwickler das ThreadX-Betriebssystem für das Anwendungssubsystem anwenden und so das Betriebssystem entsprechend den spezifischen Anforderungen ihrer Anwendung wählen. Beide Betriebssysteme sind kompatibel zu den wichtigsten Industrial-Ethernet-Protokollen, die auf RZ/N1 implementiert wurden.

Im Zuge der fortlaufenden Standardisierung baut Renesas die Unterstützung für TSN-Netzwerke kontinuierlich aus – sowohl in Hardware als auch in Software.

Lösungsmöglichkeiten

Bild 3: Die Lösungsvarianten für die Feldebene

© Renesas

Auf der untersten Ebene der Automatisierungspyramide, der Feldebene innerhalb einer Maschine oder Produktionseinheit, sind mitunter jedoch kleinere Zykluszeiten unter 100 µs gefordert. In seiner klassischen Form lassen sich mit dem Publisher-Subscriber-Verfahren keine längeren Geräteketten mit diesen Zykluszeiten realisieren, so wie zum Beispiel Ethercat oder Sercos III das heute bieten. In der Praxis bieten sich drei Lösungsmöglichkeiten an:

1. Die PLC auf unterster Steuerungsebene kommuniziert nur mit den höheren Schichten über das TSN-Netzwerk und das OPC-UA-Pub/Sub-Protokoll, damit die Interoperabilität zwischen Anlagenteilen beziehungsweise Maschinen vereinfacht wird. Die Kommunikation auf Feldebene basiert dabei weiterhin auf den etablierten Standards mit dem Vorteil, dass erprobte Technik und Geräte auf Feldebene zum Einsatz kommt und Neuentwicklungen entfallen. Allerdings wird die Feldebene wie bisher nicht durchgängig angebunden, eine Unterstützung von ‚Sensor to the Cloud‘ bleibt aufwendig.
2. Man vermeidet die heute übliche Linienstruktur und wendet sich verstärkt flacheren Hierarchien zu, um die Anzahl zu passierender Switches von der SPS zum entferntesten Feldgerät zu verringern. Je nach Anwendung erhöht dies den Verkabelungsaufwand und erfordert eine größere Anzahl an Switches. Auf der anderen Seite bräuchten Endgeräte keinen integrierten Switch mehr. Die SPS muss dann innerhalb des Netzwerk-Zyklus sehr viele kurze Ethernet Frames statt eines Summenrahmens auswerten. Hierzu ist insbesondere die Performance ihres Netzwerk-Stacks kritisch.
3. Die Feldgeräte verwenden für OPC UA Pub/Sub die bekannten Mechanismen wie Summenrahmen und Datenaustausch während des Cut-Through, um sehr kurze Zykluszeiten zu unterstützen. Ob dieses Verfahren innerhalb der momentan diskutierten Standards widerspruchsfrei anwendbar ist, muss sich zeigen. Die Ablösung eines pro­prietären Standards durch einen neuen mit vergleichbarer Leistungsfähigkeit wäre schwer zu motivieren.

Bild 3 zeigt die unterschiedlichen Lösungsmöglichkeiten auf Feldebene. Zumindest in der Anfangsphase der TSN-Einführungen werden wahrscheinlich alle drei Varianten Anwendung finden.

Welche technische Lösung sich am Ende auch durchsetzen wird, die Netzwerk-Verwaltung und das Engineering bleiben in jedem Fall eine große Herausforderung. Aber: Mit den jetzt gestarteten Aktivitäten in der IEEE/IEC 60802 und der OPC UA Foundation sind die Chancen auf die erhoffte Industrie-4.0-taugliche Gesamtlösung für ein einheitliches, echtzeitfähiges TSN-Netzwerk stark gestiegen.

Autor:
Arno Stock ist Manager in der ‚IoT and ­Infrastructure Business Unit‘ bei Renesas Electronics.