Herr Munz, seit wann kämpfen Sie für das Thema Mainstream und Offenheit in der Industrie-Automation?
Munz: Das begann schon 1982 während meines Studiums: Ich brachte die damals in Deutschland marktführenden Betriebssysteme der Office-Welt ‚CP/M‘ und das Echtzeit-Betriebssystem ‚OS-9‘ auf einer gemeinsamen Backplane mit Zilog-Z80- und Motorola-68000-Prozessoren zusammen. Ich konnte nicht verstehen, warum die Tools für OS-9 so miserabel und sündhaft teuer waren, während es bei CP/M preiswerte, leistungsfähige und weit verbreitete Werkzeuge wie den WYSIWYG-Editor ‚Wordstar‘ gab. Diese Entwicklung war auch der Impulsgeber für meine Firmengründung der LP Elektronik und das hieraus entstandene Produkt VxWin – die Kombination von VxWorks und zunächst Windows 95. Kuka Roboter kaufte 1995 diese Lösung und letztlich die ganze Firma. Seit damals ist VxWin in jedem Kuka-Roboter vorhanden, mittlerweile natürlich auf 32-Bit Windows migriert.

In den 90er-Jahren gab es im Umfeld des Feldbus-Krieges einige Offenheits-Bemühungen, bei denen Sie mitmischten.
Munz: Nach der Windows-Ausstattung aller Kuka-Roboter war es für mich naheliegend, als nächsten Schritt die Robotersteuerungen durch das Windows-Netzwerk zu vernetzen. Voller Enthusiasmus war ich deshalb damals bei der Gründung etlicher Initiativen mit dabei – IAONA, IDA, EPSG, um ein paar zu nennen –, um eine offene Kommunikationswelt zu etablieren. Doch wir waren bei vielen Dingen der Zeit mehr als 15 Jahre voraus. Lediglich die EPSG und die ab 2001 initiierte Standardisierung einer Zeitsynchronisationstechnologie für Ethernet – heute bekannt unter dem Namen IEEE 1588 – waren erfolgreich.

Aktuell setzen Sie sich für die Etablierung der Standards OPC UA und TSN ein. Was ist Ihre Motivation dabei?
Munz: Kuka ist es leid, an ein und demselben Automatisierungsgerät rund 15 unterschiedliche, proprietäre Feldbusse unterstützen zu müssen. Nur um dann mittels ein paar Bits und Bytes mit anderen Geräten immer komplexer werdende, synchrone Steuerungsaufgaben zu lösen. Gegenüber der heutigen Information Technology hat unsere Operation Technology rund 30 Jahre Rückstand. – Das kann sich die Branche nicht länger leisten.

Wir brauchen deshalb jetzt für Industrie 4.0 leistungs- und tragfähige Technologien wie OPC UA und TSN. Dabei ist OPC UA nicht nur ein weiterer Feldbus. Das Entscheidende sind die Objekt- und Service-Orientierung von OPC UA und vor allem die Möglichkeit, ja sogar der Zwang zur semantischen Selbstbeschreibung des mit OPC UA ausgestatteten Gerätes. Diese Selbstbeschreibungen von Automatisierungsgeräten sind der Schlüssel zu flexiblen Automatisierungslösungen mit Self-X – sprich Selbstkonfiguration, Selbstdiagnose, Selbstheilung – bis hin zum Einsatz von künstlicher Intelligenz.

Was stimmt Sie optimistisch, dass sich diese beiden Technologien jetzt gegen proprietäre Systeme durchsetzen?
Munz: Die Industrie-4.0-Gemeinschaft ist sich mittlerweile einig, dass als gemeinsamer M2M-Standard nur OPC UA in Frage kommt. Allerdings fehlt dem herkömmlichen Ethernet die deterministische Echtzeit-Fähigkeit im Sub-Millisekundenbereich. Daher ist es naheliegend, OPC UA mit TSN als Transportschicht zu erweitern, was aktuell bereits durch viele Aktivitäten geschieht, etwa der Pub/Sub- und TSN-Arbeitsgruppen der OPC Foundation und einiger Testbeds. Der ZVEI und der VDMA haben sich ebenfalls aktiv für OPC UA ausgesprochen und arbeiten in vielen Arbeitsgruppen an dessen Nutzbarmachung für Industrie 4.0.

Werden Sie Ruhe geben, wenn OPC UA und TSN gesetzt sind? Oder stehen weitere Standardisierungskämpfe an?
Munz: Es gibt immer noch zu tun: TSN als echtzeitfähige OPC-UA-Transportschicht löst die deterministische Kommunikation nach ‚unten‘. Was noch fehlt, ist die OPC-UA-basierte Kommunikation ‚hoch‘ in die MES/ERP/Cloud-Welten meist durch Firewalls hindurch. Die wertvollen semantischen OPC-UA-Selbstbeschreibungen der Geräte und Maschinen sollen sich für ihre Kommunikation nach ‚oben‘ schließlich ebenfalls nutzen lassen. Damit dies modern, flexibel und leistungsfähig vonstatten gehen kann, bedarf es eines Firewall-, Cloud- und Routingfähigen Transportprotokolls für OPC UA, welches mit AMQP ideale Voraussetzungen dafür mit sich bringt. Und dann, wenn die Laufzeit-Kommunikation über alle Ebenen mit OPC UA erledigt ist, steht das Thema standardisiertes Engineering auf der To-do-Liste. Nach meinem Dafürhalten mittels Automation Markup Language – kurz AML.