Echtzeit-Ethernet TSN Warum sich Kuka für TSN ausspricht

Heinrich Munz ist Senior Developer System Engineering bei Kuka.

Kuka hat die Erweiterung von OPC UA um den Ethernet-basierten Echtzeit-Standard TSN initiiert. Über die Motive und die weiteren Schritte dieses Engagements sprach Computer&AUTOMATION mit Heinrich Munz von Kuka.

Herr Munz, worin genau liegt die Motivation von Kuka, auf den Echtzeit-­Standard TSN (Time-Sensitive Networking) zu setzen?

Für Maschinenbauer ist deterministisches Echtzeit-Computing sehr wichtig. Wir müssen unsere Maschinen synchron zu deren Bewegungen teilweise im Sub-Milli­sekundenbereich von der kontrollierenden Software deterministisch steuern und regeln. Durch Industrie 4.0 kommen dabei zwei neue Anforderungen auf uns zu, die mit her­kömmlichen Methoden nicht zu lösen sind.

Erstens: Durch Gesetze nach Moore und Nielsen –  nach denen sich die Computer-Leistung beziehungsweise die Netzwerk­bandbreite alle 18 bis 24 Monate verdoppelt –  ist es zukünftig nicht mehr sinnvoll, die einzelnen Aufgaben in komplexen, zentralen Steuerungen mit mehreren Betriebssystemen und Hypervisoren zu akkumulieren. Vielmehr müssen wir die Aufgaben auf kleine, einfach beherrschbare, vernetzte Knoten verteilen und so genannte holonische Produktionssysteme bilden. Dezentralisierung "unten" auf dem Plant Floor und Zentralisierung durch Web-Services "oben" in der Cloud lautet die Industrie 4.0 Devise.

Zweitens: Manche dieser Knoten werden zukünftig nicht mehr fest installiert sein, sondern sie werden sich mobil bewegen und an den Haltestationen Echtzeitkommunikation mit den immobilen Stationen eingehen. Beispiel: Ein mobiler Roboter befördert das halbfertige Produkt an eine Bearbeitungs­station, wo ein fest installierter Roboter eine Poliermaschine trägt. Mittels synchronisierter Bewegungen polieren sie zusammen das Produkt.

Die für diese geschilderten Anforderungen notwendige Echtzeitkommunikation ist bisher nur über Feldbusse möglich. Diese wurden jedoch – wie der Name schon sagt – für die Kommunikation von E/As in das Feld entwickelt und sind mit ihren primitiven ­Bit- und Byte-Daten den modernen Anforderungen von serviceorientierter Steuerungs- zu Steuerungskommunikation – Stichwort: Peer to Peer –  nicht gewachsen. Zusätzlich erfordern sie einen immensen Engineering-Aufwand zur statischen Konfi­guration der Kommunikationsteilnehmer. Moderne, IT-basierte Netzwerke zeigen uns, dass selbst in komplexen Ad-hoc-Netzwerken – etwa Ethernet oder WiFi in Büros oder Hotels –  keinerlei manuelle Konfiguration notwendig ist, um die Kommunikation von mobilen mit beliebigen anderen Teilnehmern zu ermöglichen. Self-X lautet hierfür das übergeordnete Industrie-4.0-Stichwort, wobei das X für diesen Fall mit Configuration zu ersetzen ist, also Self-Configuration.

Sehen auch schon andere Maschinenbauer diese gehobenen Anforderungen?

Die überwältigende Zustimmung unserer OPC-Initiative von bisher mehr als 20 Firmen zeigt, dass dies nicht nur Spezialanforderungen von uns Roboterherstellern sind, sondern dass andere Automatisierungsgeräte ähnliche Anforderungen haben. Da bei Industrie 4.0 die Geräte aller Hersteller interoperabel zusammen arbeiten müssen, bedarf es hierfür eines einzigen firmenübergreifenden, internationalen Standards, hinter dem nicht wie bisher üblich nur eine Firma mit ihren unterstützenden Vereinen als treibende Kraft steckt. Verstehen Sie mich nicht falsch: Wettbewerb muss sein! Aber bitte nicht bei den Kommunikationstechnologien, sondern nur bei den Geräten selbst – wie es uns beispielhaft die Mobilfunk-Iindus­trie vorexerziert. Dadurch werden für jeden bisher proprietären Anbieter die Zielmärkte größer und der Unterstützungsaufwand für eine Vielzahl von Kommunikationsarten für die Gerätehersteller drastisch geringer. Alle Beteiligten können sich so besser auf die eigentlichen Herausforderungen konzentrieren: auf das Gestalten von effizienten und flexiblen Automatisierungslösungen.

Wie lange wird es dauern, bis die Echtzeitlösung TSN im Verbund mit OPC UA umgesetzt ist?

Das ist schwer zu sagen. OPC UA basiert heute auf einer reinen Client/Server-Architektur, welche durch die Verwendung von TCP beziehungsweise HTTP over TCP mit dessen eingebauter Sicherungsschicht nicht echtzeitfähig ist. Um OPC UA hart echtzeitfähig zu machen, muss es daher zuerst um Publisher/Subscriber-Mechanismen erweitert werden, welche auf dem echtzeit­fähigen UDP beziehungsweise direkt auf MAC-Layer aufsetzen.

Parallel dazu muss TSN ebenfalls fertig entwickelt, standardisiert und in die Infrastruktur-Komponenten eingebaut werden. Dies betrifft vor allem die Switches und deren interne Switch-Chips. Wenn das alles so weit ist, müssen die Automatisierungshersteller die notwendige Software noch in ihre Geräte implementieren. Alles dies wird noch einige Jahre dauern. Aber auch der längste Weg beginnt mit dem ersten Schritt …

TSN ist ein ziemlich komplexes Konstrukt mit sechs Untertechnologien.  Und die IEEE ist ja mit der Standardisierung auch noch nicht fertig. Kann die OPC Gemeinde dennoch schon loslegen?

Ja, beide Arbeiten können parallel erfolgen. Allerdings werden die TSN-Arbeiten sicher schneller vorangehen als die Arbeiten bei der OPC Foundation. Grund: Hinter TSN – was eine Erweiterung der Audio/Video-Bridging (AVB) Initiative darstellt – stecken nicht nur die Audio/Video-Interessierten, sondern seit kurzem auch die In-Car-Lobbyisten. Und die In-Car-Lobbyisten forcieren Ethernet nicht nur für das Entertainment im Auto, sondern auch zur Steuerung diverser – auch Functional Safety relevanter – Fahrfunktionen im Auto. Und hierfür brauchen sie harte Echtzeit. Und wir wissen alle, wie sich ein sehr großer Stückzahlenbedarf aus der Consumer-Welt auf die Umsetzungsgeschwindigkeit und die Preise technischer Neuerungen auswirkt.

Welche Schritte müssen nun auf die Automation bezogen zunächst erfolgen?

Zuerst müssen die Hersteller von Chips für Switches wie Broadcom und Marvell die neuen TSN Standards in Silizium umsetzen. Danach müssen die Switch-Hersteller Produkte mit diesen neuen Chips auf den Markt bringen. Es ist kein Zufall, dass bereits sechs Hersteller von Industrie-Switches unsere Initiative unterstützen.

Die OPC Foundation betont, dass es nicht Ziel der Echtzeiterweiterung von OPC UA um TSN sei, herkömmliche Feldbusse zu ersetzen. Ist dieser Substitutions-Gedanke denn so abwegig?

Nein, sicher nicht. Vom Prinzip her spricht nichts dagegen, auch herkömmliche Feldbus-E/As mittels OPC UA over TSN anzusteuern. Es bleibt abzuwarten, ob und wann der erste Klemmenhersteller statt eines beziehungsweise zusätzlich zu einem herkömmlichen Ethernet-basierten Feldbus-Stack auch den OPC UA TSN Stack in die Kopfstation seiner Klemmenleisten implementiert. Technisch ist das relativ einfach möglich, da TSN kaum Hardware-Anforderungen an die Endgeräte stellt, sondern vielmehr an die Infrastrukturgeräte wie Switches. Lediglich das Time Stamping des IEEE-1588-PTP-Standards, was nun als IEEE 802.1AS übernommen wurde, muss vom Ethernet-Controller unterstützt werden. Dies ist bei vielen neueren Chips schon der Fall. Falls die Kopfstation also bereits einen solchen Ethernet-Controller beinhaltet, bedarf es noch nicht mal einer Hardware-Neuentwicklung, sondern lediglich eines Firmware-Updates.

Aber klar ist auch: Obwohl die E/A-Ansteuerung durch das neue OPC UA übernommen werden kann, liegt es nicht im Interesse der Beteiligten, die Feldbusse komplett zu ersetzen. Neben der allgemeinverträglichen, in sehr kleinen Schritten erfolgenden Migration der Peer to Peer Kommunikation von bestehenden Feldbus-basierten zu TSN Anlagen, werden spezielle Feldbusse nach wie vor für Sonderaufgaben gebraucht. Ethercat EDP, Sercos, Profinet IRT, Powerlink und Varan sind etwa als Antriebsbusse durch TSN nicht sinnvoll zu ersetzen. Es bleibt dem Maschinen- und Anlagenbauer überlassen, welchen Technologie-Mix er in seinen Produkten einsetzen möchte. Das ist wie in der PC-Welt: Nach "oben" und zur Peer to Peer - Kommunikation reden alle PCs Ethernet, TCP/IP und die darauf aufbauenden Protokolle. Nach "unten" gibt es lokale, teilweise proprietäre Kommuni­kationstechnologien wie USB, Firewire, Bluetooth, Thunderbolt, Sata und PS/2.