Ethernet in der Fabrik
TSN-Netze automatisch konfigurieren
Ethernet TSN gilt als vielversprechender Ansatz zur Etablierung einer offenen Echtzeit-Kommunikation. Die Vielfältigkeit der TSN-Standards erhöht allerdings auch die Komplexität der Netzwerke. Aktuell noch einfache Management- bzw. automatische Konfigurationsmechanismen.
Im Rahmen der SmartFactory-KL forschen die Wissenschaftler des DFKI unter anderem daran, wie auf Modul-Ebene eine anwendungsgetriebene Instanziierung gekapselter Fertigungsfunktionen in Form von Produktionsmodulen realisiert werden kann. Die Gesamtanlagenstruktur setzt sich derzeit aus zehn herstellerunterschiedlichen Produktionsmodulen zusammen.
© SmartFactory-KL / C.ArnoldiSeitdem der Begriff ‚Industrie 4.0‘ auf der Hannover Messe 2011 ausgerufen wurde, steht die Digitalisie-rung und die durchgängige Vernetzung der Produktion im Fokus von Wissenschaft und Politik. Wandelnde Marktbedürfnisse fordern kundenindividualisierte Produkte bei immer kürzeren Produktlebenszyklen – modular skalierbare Anlagen mittels Plug& Play stellen hierbei einen Lösungsansatz dar.
Klassische Projektierungslösungen in der Automatisierungstechnik sehen allerdings noch kein echtes Plug&Play vor. Insbesondere in echtzeitkritischen Anwendungen müssen Steuerung und Kommunikation als integrierte Lösung projektiert werden. Hierfür stehen zwar unterstützende Engineering-Tools zur Verfügung, diese können allerdings nur für eine statische Anwendung und meist proprietäre Technologien genutzt werden. Mit anderen Worten: Es werden heute hauptsächlich proprietäre Feldbus-Lösungen eingesetzt, welche zwar die statischen Anforderungen klassischer Automatisierungssysteme erfüllen, aber das Netzwerk in herstellerabhängige Insellösungen fragmentieren und zudem keine echtes Hot-Plugging unterstützen.
Eine Technologie, die in diesem Kontext mehr und mehr von sich reden macht, ist Time-Sensitive Networking (VERLINKEN). TSN definiert eine globale und verbesserte Zeitsynchronisierung (802.1AS-Re) und einen der Kernstandards zur Umsetzung einer deterministischen Datenübertragung, den Time-Aware Scheduler (802.1Qbv). Dieser ermöglicht es, die synchronisierte Zeit zu unterteilen und so dedizierte und priorisierte Zeitschlitze zu reservieren.
Echtzeitdaten können auf diese Weise in zeitlich priorisierten Slots übertragen werden, ohne von Nicht-Echtzeitdaten beeinflusst zu werden. So lassen sich maximale Latenzzeiten von 122 µs bei Fast-Ethernet mit einer Frame-Länge von 1518 Byte und 12,2 µs bei Giga-bit-Ethernet erreichen. Weitere Mechanismen wie Schutzbänder (IEEE 802.1Qbu) und Frame-Preemption (IEEE 802.1Qbu) können die Zykluszeit auf 5,12 µs beziehungsweise 0,512 µs reduzieren.
Bild 1: TSN-Infrastruktur in modularen Fabrikanlagen: Ein standardisiertes Layer-2-Netzwerk kann dabei helfen, die Anbindung von Modulen über konventionelle Feldbus-Stacks oder Maschinenprotokolle wie OPC UA zu vereinfachen.
© DFKI / SmartFactory-KLNeben den neuen, verbesserten Ethernet-Mechanismen hat TSN das Potenzial, den nächsten Standardisierungsschritt auf Layer 2 des ISO/OSI-7-Schichtenmodells (Data-Link) durchzuführen und so eine generische Netzwerk-Infrastruktur in der Automatisierungstechnik bereitzustellen (Bild 1). Diese generische Infrastruktur kann genutzt werden, um sowohl klassischen Feldbus-Protokollen und IT-Services als auch zukünftigen Protokollen wie OPC UA Pub/Sub eine deterministische Infrastruktur zu bieten.
Verschiedene Aktivitäten zeigen das Interesse der Branche, die Stärken von TSN zu nutzen. So arbeitet eine Arbeitsgruppe innerhalb der OPC Foundation daran, die Kombination von OPC UA über TSN zu evaluieren. Auch die Profibus Nutzerorganisation sowie Sercos International möchten die Stärken von Profinet beziehungsweise Sercos III und TSN zusammenführen, um so von einer standardisierten Infrastruktur zu profitieren beziehungsweise die Protokoll-Stacks mit TSN zu vereinen. Dies soll in Zukunft außerdem dabei helfen, die Interoperabilität beim Aufbau herstellerübergreifender Produktionsanlagen auszuweiten.
Knackpunkt Netzwerk-Konfiguration
So weit, so gut. Allerdings müssen die erwähnten TSN-Mechanismen aktuell noch manuell konfiguriert werden. Die Unterteilung des Netzwerks in definierte Zeitschlitze erfordert zum Beispiel eine manuelle Berechnung und die Konfiguration jedes Netzwerk-Teilnehmers. Gerade in flexiblen und modularen Anlagen kann dies ein Hindernis bei der Einführung von TSN darstellen. Ein Wechsel einer Komponente und Änderungen an der Anlage hat häufig auch eine (Re-) Konfiguration des Netzwerkes zur Folge. Bei hohen Echtzeit-Anforderungen müssen die TSN-Mechanismen entsprechend angepasst und in das Netzwerk eingebracht werden – ein Vorgang der nicht nur zeitaufwendig ist, sondern auch potenziell Fehler verursachen kann, welche nur schwer zu diagnostizieren sind.
Mit einer ähnlichen Problematik sehen sich heute Betreiber von IT-Netzwerken konfrontiert. Diese sind mittlerweile derart komplex, dass ein manuelles Managen kaum noch realisierbar ist. Schon kleine Konfigurationsfehler können ganze Netzwerke lahmlegen. Ergo wird häufig die Entscheidung getroffen, Netzwerke möglichst unberührt zu belassen, um deren Funktionstüchtigkeit nicht zu gefährden. Angesichts der von modernen IT-Strukturen geforderten hohen Dynamik ist dies aber letztlich keine Option. Daher findet aktuell ein Umdenken in der Netzwerk-Technik statt mit dem Ziel, den stetig steigenden Netzwerk-Anforderungen gerecht zu werden.
Neue Paradigmen wie Network Functions Virtualisierung (NFV) und Software Defined Networking (SDN) spielen in diesem Zusammenhang eine wesentliche Rolle. Letzteres beschreibt das Konzept der physikalischen Trennung von Kontrollflussfunktionen und der Datenebene. Die Kontrollebene einer Netzwerk-Komponente wandert hierbei in ein zentrales Network Operating System (NOS), welches mehrere Netzwerk-Geräte steuert und überwacht.
Bild 2 zeigt den Aufbau einer SDN-Netzwerk-Architektur. Die in einem Netzwerk vorhandenen Geräte verfügen nur noch über eine Datenebene. Diese Ebene kommuniziert über eine wohl definierte Southbound API mit dem Controller. Die Programmierbarkeit des Netzwerkes wird über eine Northbound API des Controllers ermöglicht, um virtualisierte Netzwerk-Funktionen anzubieten. Zum einen kann der Controller aktiv und passiv Informationen aus dem Netzwerk sammeln und so den Zustand dieses Netzes darstellen sowie die dezentralen Daten-ebenen als eine zentrale Datenebene abstrahieren. Zum anderen können Steuerungsbefehle über den SDN-Controller in die Netzwerkgeräte gebracht werden. Die Programmierbarkeit dieser Funktionen ermöglicht potenziell auch eine vollständige Automatisierung der Netzwerk-Konfiguration. So lassen sich dynamische und ‚smarte‘ Netzwerke realisieren.
Wie das Paradigma SDN auf TSN-Netzwerke adaptiert werden kann, zeigt der Vorschlag eines TSN-Systems, welches die zentrale Konfiguration von TSN-Switches und eine Kommunikationsschnittstelle zu Netzwerk-Teilnehmern vorsieht (Bild 3). Die Idee des SDN-Controllers wird hier in zwei logisch separierte Funktionalitäten – einen Teilnehmer-Konfigurator (TK) und einen Netzwerk-Konfigurator (NK) – aufgeteilt.
Die Umsetzung von SDN auf TSN
Innerhalb eines TSN-Systems ist der Teilnehmer-Konfigurator für die Kommunikation und Konfiguration von Teilnehmern eines TSN-Netzwerks zuständig. Qualitätsanforderungen respektive Konfigurationsparameter können von den Netzwerk-Teilnehmern beziehungsweise dem TK über eine offene Kommunikationsschnittstelle, welche durch ein Teilnehmerprotokoll wie OPC UA oder auch REST umsetzbar ist, übermittelt werden. So kann der TK auch Aufgaben eines konventionellen Projektierungstools übernehmen; dies ermöglicht zwar keine dynamische Konfiguration, kann aber einen integrierten Engineering-Ansatz darstellen und bietet die Möglichkeit einer einfachen Integration von TSN in klassische Automatisierungslösungen.
Die Netzwerk-Konfiguration wird von einem (logisch) zentralen NK verwaltet. Dem Paradigma SDN zufolge wird für die Kommunikation zwischen dem Konfigurator und den Netzwerk-Komponenten – in diesem Fall den TSN-Switches – eine wohldefiniertes Southbound- beziehungsweise Netzwerk-Management-Protokoll zur Konfiguration der Kommunikationsverbindungen genutzt. Die Implementierung des Southbound-Protokolls kann sowohl über klassische Netzwerk-Management-Protokolle – wie SNMP oder Netconf/Restconf – als auch über das SDN-Protokoll OpenFlow erfolgen. Bei ersterem wird zwar nicht die strenge Definition eines SDN mit der Trennung von Kontroll- und Datenebene erfüllt; dafür lassen sich aber auch klassische Netzwerk-Komponenten erfassen und managen. In jedem Fall muss allerdings eine herstellerübergreifend und eindeutig definierte Informationsmodellierung erfolgen – bei SNMP mit der Management Information Base (MIB) beziehungsweise bei Netconf/Restconf mit der Modellierungssprache YANG. Eine einfache Umsetzung eines unterstützenden Netzwerk-Konfigurators mit dem SNMP-Protokoll hat zum Beispiel Belden/Hirschmann realisiert.
Eine Alternative zu den klassischen Management-Protokollen bietet das besagte SDN-Protokoll OpenFlow. Dieses wird von der Open Network Foundation (ONF) vorangetrieben, forciert eine vollständige Entkopplung von Kontroll- und Datenebene, und wird auch schon von IT-Unternehmen wie Google genutzt, um große Backbone-Netzwerke zu managen. OpenFlow hat direkt Zugriff auf die Hardware- beziehungsweise Datenebene einer Netzwerk-Komponente und setzt ein Match-Action Model mit Hilfe von Flow-Tabellen und Flow-Einträgen um. Letztere definieren Regeln in der Datenebene, die festlegen, an welchen Merkmalen Pakete identifiziert werden und wie diese behandelt werden sollen – sprich an welchen Port diese zum Beispiel weitergeleitet werden.
OpenFlow unterstützt aktuell zwar noch keine Regeln für eine Echtzeit-Kommunikation; diese könnten aber grundsätzlich integriert werden. Hierbei gilt es jedoch, die Granularität einer OpenFlow-Matchregel zu beachten. Eine zu hohe Granularität könnte gegebenenfalls einem Cut-Through-Verfahren im Wege stehen und die Latenzzeit erhöhen.
Bild 4: Integration von SDN in einer modularen Plug&Play-Produktionsanlage.
© DFKI / Smartfactory-KLBild 4 zeigt, wie solch ein TSN-System respektive SDN in einer modularen Fabrikanlage genutzt werden kann, um Plug&Play auch auf Netzwerk-Ebene mit spezifischen Netzwerk-Anforderungen zu realisieren. Wenn ein neuer Netzwerk-Teilnehmer – etwa ein Produktionsmodul – dem Netzwerk hinzugefügt wird, kann dieser sich mit seinen spezifischen Anforderungen beim SDN-Controller anmelden. Der zen-trale SDN-Controller führt anhand der Anforderungen des (neuen) Netzwerk-Teilnehmers eine Rekonfiguration des Netzwerkes durch, um so die geforderte Kommunikationsgüte zwischen den einzelnen Modulen bereitstellen zu können.
Abschließend lässt sich festhalten: Mit Time-Sensitive Networking lässt sich das konventionelle Ethernet nach IEEE 802.1 und IEEE 802.3 nicht nur um einen Determinismus mit niedrigen Latenzzeiten erweitert, sondern auch die Zuverlässigkeit und Sicherheit erhöhen. Insbesondere in Verbindung mit OPC UA kann TSN die Grundlage eines offenen und herstellerunabhängigen Industrie-4.0-Kommunikationsstandards bilden. Aber auch klassische Feldbus-Protokolle können von einer generischen TSN-Infrastruktur profitieren. Neben den voraussichtlich geringeren Kosten der TSN-Komponenten bietet die Infrastruktur eine hohe Investitionssicherheit. In Zukunft gilt es weiter zu evaluieren, wie TSN ein vollständiges Plug&Play-Szenario auch mit Echtzeit-Anforderungen sinnvoll unterstützen kann. Neben den notwendigen Netzwerk-Komponenten sind hierfür eine zentrale Konfigurationskomponente sowie ein einheitliches Netzwerk-Informationsmodell zu definieren.
(Der Artikel basiert auf dem VDI-Bericht 2293 Automation 2017.)
Autoren:
André Hennecke ist wissenschaftlicher Mitarbeiter in der Technologie-Initiative SmartFactory KL;
Stephan Weyer ist wissenschaftlicher Mitarbeiter am Deutschen Forschungszentrum für Künstliche Intelligenz.
Das könnte Sie auch interessieren
Belden / Hirschmann / Beck IPC
Per TSN vom Sensor in die Cloud
Die altgediente Automatisierungspyramide wandelt sich zu einer Automatisierungssäule, davon ist man bei Belden/Hirschmann überzeugt. Eine Gemeinschaftsdemo mit Beck IPC soll die Wandlung anschaulich darstellen.
mehr...Arbeitsgruppe für Netzwerksicherheit eingerichtet
Die CC-Link Partner Association (CLPA) hat eine Arbeitsgruppe zur Sicherheit von industriellem Ethernet eingerichtet. Diese soll einen Leitfaden für Anwender erstellen, die mit der offenen Gigabit-Ethernet-Technologie CC-Link IE sichere Netzwerke...
mehr...Professoren des DFKI an der Spitze der FFPA
Die kürzlich in Japan gegründete 'Flexible Factory Partner Alliance' (FFPA), ein Zusammenschluss aus bedeutenden Technologieunternehmen und Forschungseinrichtungen, hat die DFKI-Professoren Andreas Dengel (im Bild) und Hans Schotten an die Spitze...
mehr...SoftMaster kostenfrei als Open Source verfügbar
Laut Sercos International stellt Bosch Rexroth den Sercos SoftMaster als Teil seines Sercans-XS-Paketes ab sofort kostenfrei als Open Source Software zur Verfügung.
mehr...Die ersten Schritte der Digitalisierung
Echtzeit-Transparenz im Materialfluss: Dieses Ziel setzte sich das Unternehmen Miba, als es die Digitalisierung der internen Logistikabläufe anging. Wie gut aber gelang letztlich die enge Verknüpfung von ERP und MES? – Ein Erfahrungsbericht.
mehr...Wie verändert das IoT die Unternehmen in 2020?
Wie wird sich die Netzwerk-Technik in den Unternehmen in 2020 verändern? Axel Simon, Chief Technologist bei HPE Aruba, wirft einen Blick in die Glaskugel
mehr...Digitaler Zwilling revolutioniert die Wartung
Als virtuelle Repräsentanten realer Maschinen eröffnen digitale Zwillinge neue Möglichkeiten, um komplexe Industrieanlagen und -systeme zu warten und instandzuhalten. Ein Projektbericht.
mehr...Online die Maschinendaten im Griff
Riesige Datenmengen in wertvolle Informationen verwandeln – wie lässt sich dieser Ansatz einer Smart Industry umsetzen? Die Verknüpfung PC-basierter Steuerungen mit Matlab und einem IoT-Analaytikdienst auf Cloudbasis kann ein praktikabler Ansatz...
mehr...Ohne Edge und Swarm geht es nicht
Mit dem IoT haben sich die Anforderungen an die Verarbeitung von Daten geändert, die Sensoren und Aktoren von Maschinen bereitstellen. Dies muss schnellstmöglich passieren – am besten dort, wo die Daten entstehen. Edge-Knoten und...
mehr...