Stefan Hoppe, President der OPC Foundation bezieht Stellung zu den Behauptungen von Nikolai Ensslen, Synapticon

(Bild: OPC Foundation)

Nikolai Ensslen, CEO und Mitgründer von Synapticon geht in seinem Media Alert vom 19.Februar mit der OPC Foundation hart ins Gericht. Er bewertet die Entscheidung für OPC UA als Teil eines neuen IIoT-Standards kritisch: „Synapticon sieht in diesem Vorstoß keine technisch nachzuvollziehende und visionäre Entscheidung. Das auf Robotic Control Systems spezialisierte Unternehmen befürchtet, dass man damit in Sachen IIoT auf eine Sackgasse zu steuert. Als Begründung führt er diverse Argumente an, die Stefan Hoppe, Präsident der OPC Foundation, in einem offenen Brief aufgreift und widerlegt:

Stefan Hoppe, OPC Foundation: "Für sachliche und fachlich korrekte Diskussionen sind wir in der OPC Foundation immer bereit."

Stefan Hoppe, OPC Foundation: "Für sachliche und fachlich korrekte Diskussionen sind wir in der OPC Foundation immer bereit." OPC Foundation

Offener Brief – OPC Foundation, Stefan Hoppe, Präsident

Lieber Herr Ensslen,

mit Erstaunen habe ich Ihren Artikel „Fragwürdige Entscheidung“ gelesen. (Anmerkung der Redaktion: PDF ist angefügt), der einige Falschinformationen enthält.

Ich habe Ihren Artikel intensiv und mehrfach gelesen und ich 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 starte erst gar nicht, nahezu jeden einzelnen zu widerlegen; das hat Heinrich Munz bereits getan (siehe Kasten: Der Faktencheck). Nur so viel: Ihre Kernthese „Die Hersteller fokussieren auf OPC UA over TSN“ stimmt insofern nicht, da alle großen etablierten Feldbusorganisationen Systeme wie Profinet, Ethernet/IP, Ethercat, CC-Link selbst ihre Feldbusse bereits längst durch TSN tunneln können.

Sich von einem Experten wie Heinrich Munz in seinem Faktencheck attestieren lassen zu müssen, 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 eine positive Werbung für ein Unternehmen.

Es ist gute Praxis und eine Art Kodex, dass man von anderen Produkten und Technologien eigentlich nicht die Nachteile auflistet. Vielmehr positioniert man sich über die eigenen Vorteile – aufgeklärte Leser können dann zwischen den Zeilen lesen. Hier also die wesentlichen Vorteile von OPC UA:

Dafür steht die OPC Foundation

Offenheit: Bei der OPC Foundation 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 Transport-Layer, sondern auch in anderen Ebenen wie dem Zugriff und der Sichtbarkeit der Informationen. Ergebnisse des Reviews 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 sind weltweit über 50 Gruppen der Begeisterung gefolgt und definieren OPC UA Companion Specifications für ihre Branchen. Ich lade Sie herzlich ein, an der „1st World Interoperability Conference“ am 1. April in Hannover teilzunehmen. Hier können sich Besucher selbst ein Bild davon machen, wie groß die OPC UA Community ist und wie viele Arbeitskreise weltweit aktiv sind.

SoA und PubSub: Die Welten ticken unterschiedlich: Während die IT schon immer service-orientiert (SOA) denkt, 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.

Radius der Field Level Communications: OPC UA kann durchgängig in der Feldebene eingesetzt werden, muss aber nicht. Maschinen oder Anlagenteile mit einer legacy Kommunikationslösung können ebenso mittels Administration Shells eingebunden werden.

Radius der Field Level Communications: OPC UA kann durchgängig in der Feldebene eingesetzt werden, muss aber nicht. Maschinen oder Anlagenteile mit einer legacy Kommunikationslösung können ebenso mittels Administration Shells eingebunden werden. OPC Foundation

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 dem Austausch untereinander.

All diese Vorteile sind in verfügbaren Produkten implementiert und liefern konkrete Verbesserungen:

Wurde früher ein Integrator beauftragt, eine Maschine oder ein Gerät in der Fabrik an SAP anzubinden, geht das mit OPC UA heute in 10 Minuten – Standardisiert und secure

Früher hat jeder AutoID-Gerätehersteller sein eigenes Protokoll gepflegt und die Bedeutung der Daten definiert. Heute können Sie mit einem genormten OPC UA-Zugriff Produkte von verschiedenen Herstellern (Harting, Siemens, Balluff, Turck, Leuze, Sick) mit verschieden Signaltypen (RFID, 1D/2D Barcode) einbinden.

Reduzierung der Engineering Kosten: Neun Roboterhersteller (mit weiteren Anwendern und Integratoren) haben nach knapp eineinhalb Jahren Standardisierung bereits 2018 die Daten per OPC UA Schnittstelle standardisiert angeboten – und konnten so in wenigen Minuten mit Microsoft Azure verbunden werden. Standardisiert und mit Security.

fachlich inkorrekte Darstellung

Ich komme zurück auf Ihre fragwürdige Hauptaussage und die fachlich inkorrekte eindimensionale Darstellung von OPC UA (ich suche noch nach ihrer Botschaft). Meine Vermutung: Sie wollen die Aufmerksamkeit auf Ihr Thema ROS/DDS lenken? Das Roboter Operating System (ROS) war ja damals im Bitkom-Arbeitskreis Industrie 4.0 Interoperabilität bereits Ihre Mission. Dort haben wir uns auch persönlich kennengelernt. Schon damals ich habe Ihnen schon OPC UA erklärt und auch damals bereits gesagt, dass Ihre Vergleichsquellen veraltet sind.

Zum Thema ROS: Wenn ich einen Artikel lese und erkennbar so vieles erkennbar inkorrekt ist (siehe Kasten Faktencheck), warum soll ich einem Autor die anderen Aussagen glauben? Haben Sie ROS damit einen Gefallen getan?

Ich persönlich schätze die agile ROS Community. Hier 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 und standardisierte Anbindung zu haben. Dazu könnte man prüfen, ob die von Roboter-Experten innerhalb des VDMA entwickelte ‚OPC UA for Robotics‘-Schnittstelle nutzbar ist.

Aspekte, die aus ROS-Sicht fehlen, könnten erweitert werden. Oder muss hier eine eigene Companion Spec ‚OPC UA for ROS‘ 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 Kommunikationssysteme zu beherrschen und zu pflegen – auch wenn jedes System ursprünglich seinen Sinn hatte. Sie werden sich dann fragen müssen, warum Sie bei ROS ‚nach unten‘ nicht auch OPC UA-Komponenten einsetzen. Denn OPC UA mit PubSub oder optional mit TSN, wenn Determinismus benötigt wird, eben auch in dem Marktsegment eine extrem große Verbreitung bekommen wird.

Machen Sie doch mit

Die Field Level Communications im Kontext der internationalen Normungsaktivitäten rund um TSN.

Die Field Level Communications im Kontext der internationalen Normungsaktivitäten rund um TSN. OPC Foundation

Für die Zukunft: Lieber Herr Ensslen, treten Sie zum Thema OPC UA einfach mit uns in Kontakt, wenn Unklarheiten vorhanden sind. Die OPC Foundation sieht sich bewusst als offene und neutrale Organisation, die stets daran interessiert ist mit unterschiedlichsten Sichtweisen konfrontiert zu werden und gemeinsame, tragbare Lösungen zu erarbeiten. In meinem offenen Brief habe ich Ihnen konkrete Vorschläge gemacht, wo Sie Ihre Energie besser hinlenken können und aktiv gestalten können. 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

 

FAke News – der Fakten Check von Heinrich MunZ

Ob Nikolai Ensslen die Aussagen in seinem Media Alert bewusst oder durch Unwissenheit getroffen hat, ist unklar. Heinrich Munz hat in seinem LinkeIn-Blog den Media Alert von Synapticon jedenfalls zerpflückt.
Zitat Media Alert: „Eine Gruppe von OPC-Mitgliedern, in der Mehrheit Automations-Ausrüster aus dem deutschsprachigen Raum…“

Heinrich Munz: Dies sind die Mitgliedsfirmen des FLC (Field Level Communication) Steering Commitees: 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), PhönixContact, Pilz, Rockwell (10 USA), Schneider (11 France), Siemens, TTTech, Wago, Yokogawa (12 Japan)

Diese Firmen wollen OPC UA auch im Feld einsetzen.

Diese Firmen wollen OPC UA auch im Feld einsetzen. OPC Foundation

Von 23 Firmen des Field Level Communication Steering Commitee sind 12, 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 über 15 Arbeitsgruppen des VDMA, weitere im ZVEI, der Bitkom, dem LNI4.0 der DIN uvm. zu OPC UA engagieren.

Aber was viel wichtiger ist: Diese 22 Firmen decken geschätzt über 90 % der Marktanteile der Automations-Ausrüster weltweit ab! Dies ist ein wirklich globaler Standard, von dem alle anderen IoT-Domänen nur träumen können.
Zitat Media Alert: „Die Echtzeitfähigkeit wurde nachträglich eingearbeitet und ist fragwürdig…“

Heinrich Munz: 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 ggf. diverse nicht echtzeitfähige Implementierungen des Standards.
Zitat Media Alert: „Anstatt einem dynamischen und adaptiven Publish-Subscribe Prinzip folgt es dem traditionellen und starreren Server-Client Gedanken.“

Heinrich Munz: 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 Media Alert „…und hat einen sehr aufschlussreichen Vergleich von OPC UA und DDS veröffentlicht.“

Heinrich Munz: Dieser Vergleich vom August 2016 ist über 2,5 Jahre alt und längst nicht mehr aktuell.
Zitat Media Alert: „Trotz drei amerikanischer Namen wirkt die OPC UA TSN Initiative zudem ein wenig wie ein nationaler oder höchstens mitteleuropäischer Alleingang.“

Heinrich Munz: Es sind 5 Firmen aus USA, eine aus China, eine aus Indien, 3 aus Japan, eine aus Taiwan. Also 11 von 22 Firmen sind außerhalb von Europa.
Zitat Media Alert: „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.“

Heinrich Munz: Das IIC hat zusammen mit der Plattform Industrie ein White Paper herausgebracht, in dem es OPC UA der „Manufacturing Origin“ – also unserer Branche – zuordnet. Siehe das Bild „IIoT connectivity stack from IICF“ 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. Im Blog heißt es: “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.”

Mit vier unterschiedlichen vermischten Standards ist schwerlich eine Interoperabilität auf dem Plant Floor oder in sonst einer Domäne hinzukriegen.Hier geht es zum Blog-Eintrag im Original von Heinrich Munz.

Sie möchten gerne weiterlesen?