Anmerkung der Redaktion: Dieser offene Brief ist eine Antwort von Stefan Hoppe, Präsident der OPC Foundation, auf den sehr kontrovers diskutierten Kommentar „Fragwürdige Entscheidung: OPC UA als Teil eines neuen IIoT-Standards“ von Nikolai Ensslen, CEO von Synapticon. Die in beiden Beiträgen vertretenen Meinungen entsprechen nicht zwingend den Ansichten unserer Redaktion.
Lieber Herr Ensslen,
mit Erstaunen habe ich Ihren Artikel „Fragwürdige Entscheidung“ gelesen, welcher im Original in A&D am 5. Februar 2019 im Internet veröffentlicht wurde. Leider gibt es auf der A&D-Webseite keine Möglichkeit, einen Artikel direkt zu kommentieren – eigentlich schade, da so nicht gewährleistet werden kann, dass Falschinformationen direkt an der Quelle markiert werden und sich eben unkommentiert bei den Lesern weiterverbreiten können.
Was ist Ihre Nachricht?
Ich habe Ihren Artikel nun intensiv und sogar mehrfach gelesen und frage mich: „Was ist eigentlich Ihre Intention, was ist Ihre Nachricht?“ Ihr Artikel enthält so viele und einfach erkennbare „Fake-News“, dass ein reines Erhaschen von Aufmerksamkeit kaum Ihr Ziel gewesen sein kann. Ich möchte hier nicht einzelne Sätze widerlegen, nur so viel: Die Hauptaussage „Die Hersteller fokussieren auf OPC UA over TSN“ stimmt insofern nicht, da alle großen, etablierten Feldbusanbieter wie Profinet, EthernetIP, EtherCAT, CC-Link ... selbst ihre Feldbusse bereits längst durch TSN tunneln können.
Sich von einem Industrievertreter (Herr Munz) attestieren zu lassen, dass man scheinbar seit Längerem nicht auf der Höhe der Informationen ist und auch IIC-Standardisierungsaktivitäten falsch einschätzt, ist ja nicht gerade positive Werbung für ein Unternehmen.
Es ist gute Praxis und eine Art Kodex, dass man von anderen Produkten und Technologien eigentlich nicht Nachteile auflistet – sondern man positioniert eigene Vorteile –, die aufgeklärten Leser können dann zwischen den Zeilen lesen. Hier die ganz einfachen wesentlichen Vorteile von OPC UA:
Offenheit: Bei der OPC Foundation (UA gestrichen) als Non-Profit-Organisation mit 650 (!) Mitgliedern sind Entwicklungen intrinsisch getrieben. Spezifikationen, Code und auch der Zugang zu den Zertifizierungslaboren stehen auch Nicht-Mitgliedern zur Verfügung – auch die OPC-UA-Technologie.
Security by Design: Von Beginn an wurde Security bei der Planung von OPC UA berücksichtigt. Nicht nur im Transportlayer, sondern auch in anderen Ebenen wie zum Beispiel dem Zugriff und der Sichtbarkeit der Informationen. Ergebnisse des Review vom BSI sind öffentlich im Internet einsehbar.
Modelling: Die Standardisierung der Daten und Interfaces inklusive der Bedeutung ist ein großes Bestreben von Industrie 4.0 – aktuell definieren 50+ Gruppen weltweit OPC UA Companion Specifications für ihre Branchen im Bereich Fabrik- und Prozessautomation, Energie, Öl & Gas, Pharmazie, industrielle Großküchengeräten et cetera. Meine herzliche Einladung an Sie zur 1st World Interoperability Conference am 1. April, hier können Sie sich als Besucher selbst einen Eindruck verschaffen, wie groß die OPC UA Community ist und wie viele Arbeitskreise unterwegs sind.
SoA und PubSub: Die Welten ticken unterschiedlich: Während die IT schon immer serviceorientiert (SoA) betrieben hat, ist in der Automatisierung auf unterster IO-Ebene die zyklische PubSub-Verarbeitung gefordert. OPC UA bietet beides! Gestartet mit SoA ist die OPC-UA-Architektur erweiterbar.
Eco-System: OPC UA ist das weltweit größte Eco-System für industrielle Interoperabilität. Produkte/Geräte, erstellt mit Toolkits von verschiedenen Anbietern, agieren sofort miteinander. Interoperability Plugfeste auf allen Kontinenten testen Produkte, dienen aber auch maßgeblich der Vernetzung von Entwicklern verschiedenster Unternehmen.
All diese Vorteile sind in am Markt verfügbaren Produkten implementiert und liefern konkrete Verbesserungen:
Früher wurde ein Integrator beauftragt, eine Maschine oder ein Gerät in der Fabrik an SAP anzubinden. Heute geht das in 10 min. Standardisiert. Mit Security.
Früher hat jeder Auto-ID-Gerätehersteller sein eigenes Protokoll gepflegt und die Bedeutung der Daten definiert. Heute können Sie Produkte von verschiedenen Herstellern (Harting, Siemens, Leuze, Sick, Balluff, Turck, ...) mit verschieden Signaltypen (RFID, 1D/2D Barcode) mit einem genormten OPC-UA-Zugriff einbinden: Reduzierung der Engineering-Kosten.
Neun Roboterhersteller (mit weiteren Anwendern und Integratoren) haben nach 1,5 Jahren Standardisierung erstmals öffentlich 2018 die gleichen genormten Daten per OPC-UA-Schnittstelle angeboten – und konnten so in wenigen Minuten mit Microsoft Azure verbunden werden. Standardisiert. Mit Security.
Ich komme zurück auf Ihre fragwürdige Hauptaussage und die fachlich unkorrekte eindimensionale Darstellung von OPC UA ... Ich suche noch nach ihrer Botschaft: Vermutlich wollen Sie Aufmerksamkeit auf Ihr Thema ROS/DDS lenken? ROS war damals im Bitkom-Arbeitskreis Industrie 4.0 Interoperabilität bereits Ihre Mission – daher kennen wir uns auch persönlich, und ich habe Ihnen damals schon OPC UA erklärt und auch damals bereits gesagt, dass Ihre Vergleichsquellen veraltet sind.
Also das Thema ROS. Wenn ich einen Artikel lese und so viel erkennbar unkorrekt ist … warum soll ich einem Autor diesen Teil glauben? Haben Sie ROS damit einen Gefallen getan?
Ich persönlich schätze die agile ROS Community – hier also meine konstruktiven Vorschläge an Sie:
IT-Anbindung für ROS: ROS benötiget OPC UA, um „nach oben“ in die IT (SCADA, MES, ERP, Cloud) eine schnelle, sichere, standardisierte Anbindung zu haben. Dazu könnte man prüfen, ob die von Roboter-Experten innerhalb des VDMA entwickelte „OPC UA for Robotics“-Schnittstelle passt. Aus ROS-Sicht fehlende Aspekte könnten erweitert werden. Oder muss hier eine eigene „OPC UA for ROS“ Companion Spec erarbeitet werden?
Harmonisierung Companion Specs: Wenn Sie dickere Bretter bohren wollen, dann helfen Sie bei der Harmonisierung der verschiedenen Companion Specs … Jede Maschine wird ein Typenschild, OEE-Daten, Energiedaten enthalten – auch Teile einer MES-Schnittstelle. Können Sie hier zu Lösungen beitragen?
Field-Level-Anbindung an ROS: In einiger Zeit werden Sie feststellen, dass es mühsam ist, verschiedene Kommunikationssystem zu beherrschen und zu pflegen – auch wenn jedes System ursprünglich seinen Sinn hatte. Sie werden sich in einiger Zeit fragen müssen, warum Sie von ROS „nach unten“ nicht auch OPC-UA-Produkte einsetzen – weil OPC UA mit PubSub, und optional TSN, wenn Determinismus benötigt wird, eben auch in dem Marktsegment eine extrem große Verbreitung bekommen wird.
Lieber Herr Ensslen, treten Sie für die Zukunft zum Thema OPC UA einfach in Kontakt, wenn Unklarheiten vorhanden sind. Die OPC Foundation sieht sich bewusst als offene und neutrale Organisation, die stets daran interessiert ist, mit unterschiedlichen Sichtweisen konfrontiert zu werden und gemeinsame, tragbare Lösungen zu erarbeiten. Ich habe Ihnen konkrete Vorschläge gemacht, wo Energie besser hingelenkt werden könnte, und etwas aktiv zu gestalten und eine Welle vorne zu reiten, ist sicherlich für das eigene Unternehmen positiv. Und aus eigener Erfahrung: Es macht zudem noch Spaß.
Ihr Stefan Hoppe
Präsident OPC Foundation
Nachfolgend finden Sie den in Hoppes Brief erwähnten LinkedIn-Kommentar von Heiner Munz. Die Zitate beziehen sich auf Ensslens Aussagen:
Zitat: Eine Gruppe von OPC-Mitgliedern, in der Mehrheit Automations-Ausrüster aus dem deutschsprachigen Raum …
Das folgende sind die Mitgliedsfirmen des FLC (Field Level Communication) Steering Committees:
ABB, B&R, Beckhoff, Bosch Rexroth, Cisco (1 USA), Hilscher, Belden/Hirschmann (2 USA), Huawei (3 China), Intel (4 USA), Kalycito (5 Indien), Kuka, Mitsubishi (6 Japan), Molex (7 USA), Moxa (8 Taiwan), Omron (9 Japan), PhoenixContact, Pilz, Rockwell (10 USA), Schneider (11 France), Siemens, TTTech, Wago, Yokogawa (12 Japan)
Von 23 Firmen des Field Level Communication Steering Commitee sind mit zwölf, also die Mehrheit nicht aus dem deutschsprachigen Raum. Und das sind nur die Firmen, welche aktiv im Steering Committee arbeiten und sich finanziell erheblich an der Weiterentwicklung des FLC-Standards beteiligen. Nicht mitgezählt sind hierbei alle anderen Firmen, welche sich in allein > 15 Arbeitsgruppen des VDMA, weitere im ZVEI, der Bitkom, dem LNI4.0 der DIN und vielen mehr zu OPC UA engagieren.
Aber was viel wichtiger ist: Diese 22 Firmen decken geschätzte > 90 Prozent der Marktanteile der Automationsausrüster weltweit ab! Dies ist ein wirklich globaler Standard, von dem alle anderen IoT-Domänen nur träumen können.
Zitat: Die Echtzeitfähigkeit wurde nachträglich eingearbeitet und ist fragwürdig …
Nicht die Echtzeitfähigkeit von OPC UA ist fragwürdig. Die wurde mit der Pub/Sub-Spezifikation vom Januar 2018 klar definiert. Fragwürdig sind gegebenfalls diverse, nicht echtzeitfähige Implementierungen des Standards.
Zitat: Anstatt einem dynamischen und adaptiven Publish-Subscribe-Prinzip folgt es dem traditionellen und starreren Server-Client-Gedanken ...
Offensichtlich ist es dem Autor des Artikels entgangen, dass es seit Januar 2018 die verabschiedete Publisher/Subscriber Spec #14 für OPC UA gibt.
Zitat: … und hat einen sehr aufschlussreichen Vergleich von OPC UA und DDS veröffentlicht.
Dieser Vergleich vom August 2016 ist circa 2,5 Jahre alt und längst nicht mehr aktuell.
Zitat: Trotz drei amerikanischer Namen wirkt die OPC UA TSN Initiative zudem ein wenig wie ein nationaler oder höchstens mitteleuropäischer Alleingang.
Es sind fünf Firmen aus USA, eine aus China, eine aus Indien, drei aus Japan, eine aus Taiwan. Also elf von 22 Firmen sind außerhalb von Europa.
Zitat: 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.
Das IIC hat zusammen mit der Plattform Industrie ein Whitepaper herausgebracht, in dem es der „Manufacturing Origin“ – also unserer Branche – OPC UA zuordnet. Siehe das Bild „IIoT connectivity stack from IICF“ von hier. Selbst RTI, der „Erfinder“ von DDS, hat diese Sachverhalte in einem Blog beschrieben.
Und nein, das IIC will nicht „einen offenen, freien und globalen Standard für das IIoT“ etablieren, sondern, Zitat aus dem Blog: „The IIC … has not specified any single standard, but has recommended four core standards that are close matches for the connectivity requirements of IIoT systems: DDS, OneM2M, WebServices and OPC-UA (Figure 3)“
Mit vier unterschiedlichen vermischten Standards ist schwerlich eine Interoperabilität auf dem Plant Floor oder in sonst einer Domäne hinzukriegen.
Zitat: … und ein Risiko erschaffen, dass sich einige deutschsprachige Automations-Ausrüster in ihrem Digitalisierungsbestreben in eine Sackgasse bewegen.
Das hatten wir schon ...