Anmerkung der Redaktion: Dieser Kommentar wird sehr kontrovers diskutiert. Lesen Sie hier die Stellungnahme von Stefan Hoppe, Präsident der OPC Foundation. Die in beiden Beiträgen vertretenen Meinungen entsprechen nicht zwingend den Ansichten unserer Redaktion.
OPC UA kann auf verschiedenen elektronischen Kommunikationsstandards realisiert werden, u.a. auch den diversen proprietären Industriefeldbussen. Eine Gruppe von OPC-Mitgliedern, in der Mehrheit Automations-Ausrüster aus dem deutschsprachigen Raum, machen sich dafür stark, OPC UA in Kombination mit TSN (Time-Sensitive Networking) als zentralen Standard zu etablieren. Bei TSN geht es um die Erweiterung von Standard-Ethernet für industrielle Anforderungen.
TSN als wichtige offene Alternative
Angesichts des Dilemmas, in dem sich die Welt der industriellen Automation befindet, seit Hersteller von Steuerungen auf die Idee kamen, mit proprietären Feldbussen geschlossene Ökosysteme zu schaffen, die eine eigene Vormachtstellung in der jeweiligen Fabrik zu etablieren und zu unterhalten ermöglichen, ist die Unterstützung von TSN als offene Alternative sehr zu begrüßen.
Vergleicht man den Zustand in der Automation bis heute mit der IT, so entspricht das in etwa einer Welt, in der Größen wie Google, Amazon, IBM, SAP und Microsoft jeweils ihr eigenes Internet betreiben. Ihr IBM Notebook würde Watson-basierte Dienste und Lotus Notes e-Mail anbieten (über das sie nur andere IBM Kunden erreichen könnten), während Ihre Kollegen im Einkauf auf ihren SAP Terminals ebenfalls in einer geschlossenen Umgebung unterwegs sind und sie privat mit Ihrem Amazon Smartphone einkaufen und mit ihrem anderen Telefon von Google das Netz durchsuchen. Moment, welches Netz?
Die Welt wie wir sie heute kennen würde schlichtweg nicht existieren. Denn die Dynamik, die das Internet ermöglicht, wird durch Offenheit gewährleistet. Entsprechend groß ist das Potential, dass TSN für die Automation mit sich bringt. Man könnte soweit gehen und sagen, durch TSN wird Industrie 4.0 zur Korrektur von vergangenen Fehlern bei der Feldbus-basierten Industrie 3.0.
Die Gelegenheit für eine bessere Lösung wurde verpasst
Wie steht es aber nun um die Entscheidung, auf TSN aufbauend OPC UA als weiteren Standard für Interoperabilität zu bestimmen? Leider ist die sehr viel weniger zu begrüßen, technisch als auch politisch. Aus der Entscheidung für OPC UA resultiert zwar kein unmittelbarer Schaden, aber es wurde vorläufig eine Gelegenheit verpasst – für eine noch bessere Lösung Denn das, was OPC UA repräsentiert, ist mehr als ein Kommunikationsstandard. Man bezeichnet diese Kategorie an Technologie auch als Middleware, Infrastruktur für die Entwicklung komplexer, verteilter Softwareprojekte.
Die für ein Softwareprojekt verwendete Middleware ist für den Entwicklungsprozess und die beteiligten Entwickler eine Entscheidung von großer Tragweite. Sie bedeutet Möglichkeiten oder Begrenzung, Begeisterung oder Depression – für die Menschen, die technologische Produkte letztlich für uns alle erschaffen. Man konnte dies in den vergangenen Jahren ganz deutlich z.B. in der Welt der Robotik, insbesondere der Service-Robotik bzw. mobilen Robotik beobachten: bei ROS, dem Robot Operating System, handelt es sich zu einem wesentlichen Teil um eine Middleware.
Die Anzahl autonomer Robotersysteme und selbst autonomer PKW-Prototypen, die ROS nicht nutzen, ist verschwindend. Die Plattform ist der de-facto Standard in der Entwicklung intelligenter Systeme – vollkommen aus eigener Kraft gewachsen, ganz ohne Industriekonsortium. Erst spät sind die ROS Industrial Consortiae entstanden, die die Nutzung von ROS im industriellen Kontext unterstützen und großen Firmen einen Ansprechpartner in der sonst für diese schwer greifbaren Open-Source-Community zur Verfügung stellen.
Eine Open-Source-Community, die die Welt verändert
Und dies sollte dem an einer besseren Zukunft der Automation Interessierten eine wichtige Beobachtung sein: ROS ist eine meritokratische Open Source Community, die mit intrinsischer Energie die Welt verändert. Geschaffen von einigen der besten Mechatroniker und Softwareentwickler der Welt, für die besten Mechatroniker und Softwerker der Welt. Konfrontiert mit verschiedenen Problemen aus der Welt der Massenprodukte, also Consumerprodukten vom Rasenmäher bis zum PKW und anderen aus der Welt der Industrierobotik, hat sich der Kern dieser Community in den vergangenen Jahren damit beschäftigt, ROS in Zukunft technisch und politisch auf die beste Basis zu stellen.
Dazu musste vor allem die vormals proprietäre ROS Middleware auf einen Industriestandard gebracht werden, dem missionskritische Anwendungen vertrauen, der zertifizierbar ist – der aber zugleich weiterhin die so wichtigen Freiheiten und Werkzeuge für die Entwickler unterstützt und einen nicht an eine bestimmte, kommerzielle Implementierung bindet. Das extrem kritische und vor allem unvoreingenommene Assessment brachte DDS (Data Distribution Service) als den Standard der Wahl hervor. DDS ist ein in missionskritischen Anwendungen im Bereich Raumfahrt, Militär, Medizintechnik und der Öl- & Gasindustrie seit vielen Jahren etablierter und breit unterstützter Standard, der in der Object Management Group (OMG) verwaltet wird, die auch für verschiedene sehr erfolgreiche, wettbewerbsneutrale Standards für modellbasierte Entwicklung verantwortlich ist.
Offensichtliche Anknüpfungspunkte mit enormen Potenzial
Wenden wir den Blick von der „Edge“, wo die Robotik sitzt, in die „Cloud“ – dem anderen für Industrie 4.0 zentralen Thema. Das IIoT der Automation ist in der Zukunftsvision ein Teil des allgemeineren IoTs der IT Welt – und soll natürlich auch mit diesem interagieren. Unter anderem in den Bereichen Produktentwicklung (CAD), Warenwirtschaft (ERP) & Einkauf, Logistik (SCM) und nicht zuletzt des e-Commerce, gibt es auf der Cloud-Seite sehr offensichtliche Anknüpfungspunkte in Richtung Fabrik mit enormem Potential.
Erneut haben wir es in diesen Bereichen, fast noch offensichtlicher als in der Robotik, mit Feldern zu tun, in denen Softwareentwickler Technologie und Produkte gestalten, die uns bewegen und damit den Lauf der Dinge in der Wirtschaft inzwischen so stark beeinflussen wie kaum ein anderer Faktor. Eine Tatsache übrigens, der man sich in Deutschland bekannter- und beklagterweise nur langsam nähert.
Anders als in der Robotik, hat man sich in der allgemeinen IT weniger stark (und wenig überraschend) auf eine einzelne Plattform wie ROS eingeschossen. Es gibt unendlich viele Ökosysteme, in denen Software für das IoT entwickelt wird. Und dennoch hat sich ein quasi-Standard etabliert, der breite Unterstützung erfährt: MQ für Message Queing, in der Form von Middleware bekannt und verbreitet durch verschiedene Implementierungen, wie z.B. MQTT oder ZeroMQ. Wiederum Open Source Projekte vor dem Hintergrund einer meritokratischen Community. Wie bei ROS/DDS handelt es sich hier um Technologie, die aus guten Gründen Unterstützung findet von denen, die es am besten wissen.
OPC UA eignet sich nur bedingt für dezentrale System
Wie steht es nun um die technische Beschaffenheit von OPC UA? OPC wurde zunächst in einer reinen Microsoft-Welt erarbeitet, als Lösung eines Windows-spezifischen Problems mit komponentenorientierter Software. OPC UA mag eine Windows-unabhängige, „verbesserte Rezeptur“ von OPC sein, hat aber immer noch mindestens zwei schwerwiegende Mängel: Die Echtzeitfähigkeit wurde nachträglich eingearbeitet und ist fragwürdig – die TSN-Unterstützerguppe hat es sogar als zentrales Thema definiert, dies zu korrigieren.
Und für wirklich dezentrale Systeme eignet sich OPC UA aus Architekturgründen nur bedingt: Anstatt einem dynamischen und adaptiven Publish-Subscribe Prinzip folgt es dem tranditionellen und starreren Server-Client Gedanken. Angelo Corsaro, u.a. in der OMG engagiert, zählt sicher zu den versiertesten Menschen beim Thema Interoperabilität und dezentrale Architekturen und hat einen sehr aufschlussreichen Vergleich von OPC UA und DDS veröffentlicht.
Eine neue Parallelwelt entsteht
Vor diesem Hintergrund wird deutlich, dass die Entscheidung für OPC UA der OPC UA TSN Unterstützer eine untechnische und politisch nicht ausreichend überlegte Entscheidung ist. Anstatt sich globalen, offenen und ausgreiften Standards anzuschließen, die an den Übergangsbereichen der Automation hin zu IT und Robotik gut etabliert sind, kocht man sich die nächste eigene Suppe, schafft eine neue Parallelwelt. Trotz drei Amerikanischer Namen wirkt die OPC UA TSN Initiative zudem ein wenig wie ein nationaler oder höchstens mitteleuropäischer Alleingang.
Nur so viel: Das Industrial Internet Consortium (IIC) mit mehr als 250 internationalen Mitgliedern, in seiner Absicht das W3C für die Industrie, also einer wirklich umfassenden Organisation zur Etablierung eines offenen, freien und globalen Standards für das IIoT, ist eine Suborganisation der OMG. Was auf den ersten Blick wie eine Pionierbewegung aussieht (OPC UA TSN), könnte sich somit bald als isolierte Splittergruppe herausstellen.
Die Fixierung auf OPC UA kann in eine Sackgasse führen
Das Bestreben der OPC UA TSN Gruppe ist grundsätzlich gut gemeint und aufgrund der Promotion von TSN ein klarer Schritt nach vorne. Durch die Fixierung auf OPC UA jedoch wird die Wirkung stark gehemmt und ein Risiko erschaffen, dass sich einige deutschsprachge Automations-Ausrüster in ihrem Digitalisierungsbestreben in eine Sackgasse bewegen. Mit direkter Auswirkung auf die Zukunftsfähigkeit der Standorte D-A-CH und Frankreich.
.jpg "Nach dem Hype: der Weg zu 5G Industrial IoT (IIoT)")
