Stefan Hoppe, Präsident der OPC Foundation wirft im Interview einen Blick zurück und erläutert die Herausforderungen von morgen.

Herr Hoppe, wann und unter welchen Startbedingungen erfolgte der Startschuß für OPC?

Stefan Hoppe: Die Geschichte der OPC Foundation ist gut dokumentiert: 1995 hat sich eine Task-Force – quasi als Vorläufer der OPC Foundation – aus den Firmen Fisher-Rosemount, Rockwell Software, Opto 22, Intellution und Intuitive Technology gebildet. Innerhalb nur eines Jahres entstand eine grundlegende Spezifikation. Dieser Standard, genannt OLE for Process Control, basierte auf der damals verbreiteten Microsoft COM/DCOM-Technologie und funktionierte wie ein Gerätetreiber. Dieser ermöglichte es, SPS-Steuerungen in die Lage zu versetzen Live-Daten, Alarme und historische Daten an SCADA und MES-Systeme zu liefern. Eine vereinfachte Spezifikation v1.0 folgte in 1996 – parallel erfolgte die offizielle Gründung der OPC Foundation im April 1996, mit Siemens als einziger europäische Firma. 
Im Jahr 2003 begann die OPC Foundation dann mit der Trennung von Diensten und Daten, OPC Unified Architecture (OPC UA) erhielt eine dienstorientierte Architektur. Die Technologie wurde entwickelt, um nahtlos einen sicheren und zuverlässigen Informationsaustausch vom Sensor bis zur IT, unabhängig von Betriebssystemen, zu gewährleisten. Die Veröffentlichung der OPC UA Spezifikation v1.0 erfolgte am 26. Juli 2006. Um die weltweite Adaption zu erleichtern, wurde OPC UA als vollwertiger IEC-Standard unter der Nummer IEC 62541 veröffentlicht. Heute im Jahr 2023 sind wir bei der OPC UA Version 1.05 angekommen. Somit ist OPC UA seit 17 Jahren ohne Kompatibilitätsbruch am Markt verfügbar.

Was sind Ihrer Meinung nach die jetzt und in Zukunft am  höchsten zu nehmenden Hürden?

Die größte Hürde liegt darin, die Anwender von der Leistungsfähigkeit und Praktikabilität von OPC UA zu überzeugen. Es ist ja immer noch so, dass viele Nutzer noch von der Reihenfolge ausgehen, dass man zunächst ein Datenprotokoll auswählt, dann im zweiten Schritt die notwendigen Daten zur Verfügung stellt. Später, als dritter Schritt folgt eventuell noch die Betrachtung der Security-Aspekte. Das ist in der heutigen Welt aber nicht mehr zielführend, beziehungsweise im Ergebnis mit viel Aufwand verbunden. OPC UA bietet wie ein Schweizer Taschenmesser viele Funktionen: Daten werden zuerst modelliert und Protokolle inklusive Security stehen bereits zur Verfügung und müssen eben nur konfiguriert werden. Die einzelnen Werkzeuge des Taschenmessers sind aber sehr vielfältig und man muss auch nicht immer das größte Messer mit allen Features einsetzen – es tut´s auch oft ein kleineres Messer! In der Technik gesprochen: OPC UA lässt sich skalierbar mit Features auslegen – zum Beispiel muss es als Digitaler Zwilling in der Cloud kein TCP, UDP und auch kein TSN implementieren, sondern sinnvollerweise vielleicht eben nur MQTT und REST. Andersrum erwarte ich nicht, dass Feldgeräte zwangsläufig direkt OPC UA via REST-Schnittstellen anbieten.

»Wir sollten nicht leichtfertig immer wieder neue Technologien ins Feld werfen, sondern besser existente Technologien um fehlende Features ergänzen!«

Eine Herausforderung ist sicherlich, dass die Liste der verfügbaren Features zwar öffentlich gut dokumentiert, aber dennoch inzwischen so groß ist, dass viele den Überblick darüber verlieren und glauben Dinge erfinden zu müssen, welche bereits lange als OPC UA Feature vorhanden sind. Als Beispiel nenne ich File-Transfer welches seit 2009 in OPC UA definiert ist: OPC UA ermöglicht Verzeichnisse zu durchsuchen, Dateien neu anlegen, editieren, Inhalte einfügen oder entfernen, und Dateien zu löschen. OPC UA kann somit Online – also Livedaten - und Offline-Daten zum Beispiel AML-Konfigurationsdaten einlesen oder transferieren.  Mehr Daten gibt es nicht – oder?

Die IT- und die Automatisierungsanbieter tun sich ja bekanntermaßen etwas schwer damit, die Digitalisierung der Fabrik miteinander umzusetzen. Welches sind Ihre größten Befürchtungen, was den IT/OT-Konflikt betrifft?

Leider reden IT und OT nicht wirklich miteinander, sondern meistens übereinander. Zudem ist das menschliche Syndrom ‚Not invented here’ das größte Problem. Auf OPC heruntergebrochen haben sich viele Menschen im Jahr 2008 einmal ein Bild von OPC UA gemacht und es als ‚moderneres OPC-Classic Protokoll’ verkannt – das wird dem heutigen OPC UA aber nicht mehr gerecht.  OPC UA ist mittlerweile aber viel mehr und besteht zusammengefasst aus drei Kernen. Erstens: OPC UA ist eine leistungsfähige Modellierungssprache – für die Beschreibung und das Verhalten von nahezu allem: Geräten, aber auch Diensten beziehungsweise Prozessen. Zweitens:  Diverse Protokolle für die OT und IT-Welt sind bereits integriert und wie bereits erwähnt ist auch Punkt drei, die Security inklusive – und das Schöne dabei: alles kann erweitert werden. 

OPC UA ist mit diesen drei Kernen von Anfang an für das Zusammenwachsen von IT und OT geschaffen worden – daher skaliert zum Beispiel Modellierungssprache eben in die OT-Welt zur Beschreibung eines Roboters und seinem Verhalten und der Interaktion ebenso wie die Beschreibung von Diensten oder einem Digitalen Zwilling oder Data Spaces in der IT-Welt in der Cloud. 
Das Angenehme daran: Die von Domain-Experten standardisierten Informationen lassen sich somit einfach in der Cloud referenzieren und müssen nicht erst in andere weniger leistungsfähige Meta-Modellierungssprachen umgemappt werden. 

Wünsche und Visionen

Wo hängt es denn derzeit konkret?

Ich habe jüngst viele Gespräche mit Vertretern und Architekten der AAS-Verwaltungsschale auf dem Automation Kongress in Baden-Baden geführt und gefragt, was eigentlich der neu zu lösende Use-Case ist, welche mit der Kombination von OPC UA und AML nicht gelöst werden könnte. Schnell wird dann OPC UA in die Schublade gesteckt „OPC UA macht nur operative Live-Daten – die AAS sammelt Daten über den Lebenszyklus“. Diese Antwort gibt aber keinerlei Aufschluss darüber, welches Feature in der Kombination OPC UA mit AML denn tatsächlich fehlt. Und falls ein Feature fehlt, warum engagiert man sich nicht innerhalb der bestehenden Organisationen und bringt ein solches neues Feature ein? 

»Das Interesse der IT-Welt ist unglaublich groß und somit wird sich OPC UA mit seinen Schnittstellen REST und OPC UA over MQTT sehr viel weiter in der IT-Welt etablieren.«

Wenn ein Feature fehlt, sollte man das nicht zum Anlass nehmen ein eigenes, komplett neues System zu bauen, welches zu einem bewährten bestehenden System inkompatibel ist! Das sorgt doch nur für Konfusion am Markt: Was baue ich mit dem etablierten System und was baue ich mit dem neuen System auf? Die Folge wäre doch: Kleine und mittlere Unternehmen sind schlicht überfordert und stoppen jegliche Integration von Standards, es verhindert somit die Adaption und das Zusammenwachsen der IT und OT. Etwas ketzerisch: Ein legitimer Sinn um solch ein neues System zu bauen ist vielleicht das Mitnehmen von Forschungsgeldern – aber liefert das wirklich auch pragmatische Innovationen?

Was würden Sie sich denn hinsichtlich eines Konfliktabbaus zwischen OT und IT von der IT-Branche wünschen?

Den Wunsch ‚Einfach mal Zuhören’ an die IT-Branche zu richten ist zu kurz gegriffen: Der Konflikt IT mit OT verläuft ja innerhalb aller Großkonzernen der Anwender ebenso wie bei den Zulieferern. Das gegenseitige Verständnis ist nicht gegeben: Die IT-Welt versteht wenig, welche Randbedingung ein deterministischer Feldbus braucht, warum OT die Netze trennen will und warum auf unterster OT-Ebene auf Sensor und Controller ein REST-Interface oder eine AAS keinen Sinn macht. Das gleiche gilt andersrum für reine OT-Konzepte, welche nicht in die IT-Welt skalieren. Jeder geht davon aus, dass sein eigenes Konzept auch in die andere Welt skaliert und dort adaptiert wird.
OPC UA ist von vornherein gemeinsam von IT- und OT-affinen Personen für die Zusammenführung von IT/OT konzipiert worden und daher das erfolgreiche Leuchtturm-Projekt von der Industrie für die Industrie getrieben: Innovation getrieben ohne jegliche Steuergelder – dafür aber seit 17 Jahren ohne Kompatibilitätsbruch.

Was kann die OT-Branche tun, um ihre Interessen besser zu wahren?

Es gilt das Gleiche wie bei der vorigen Frage: Die OT-Welt sollte nicht meinen, dass alle IT-Konzepte sowieso nicht für die OT-Welt passen. Mal unvoreingenommen zuhören, wie und wo Virtualisierung- und Docker-Konzepte gut passen und wo nicht. Und bitte ebenso nicht versuchen, OT-Lösungen in die IT-Welt zu treiben. Das funktioniert genauso wenig. Mein Appell: bitte miteinander reden, in Use-Case denken und gemeinsam lösen! Bitte nicht erst eine Lösung finden und dann das Problem dazu suchen!

Welche Vision treibt Sie persönlich weiter an?

OPC UA hat sich ja gewandelt in der Wahrnehmung von einem reinen Standard der letzten Meile zu SPS-Steuerungen, hin zu einem Standard, welcher nun über 105 Branchen mit Informationsmodellen abdeckt und mit OPC UA over MQTT als Bindeglied der OT zu IT Welt steht. 
Aber ich glaube, OPC UA kann noch ganz andere Tore aufstoßen! Bestes Beispiel: Die REST-Erweiterung als OPC UA Schnittstelle wurde im Jahr 2016 vom Open62541 Stack in einem Forschungsprojekt öffentlich vorgestellt. Auf Wunsch der Industrie erweitern wir dieses REST-Interface derzeit mit dem Ziel, einfachen Zugang zu den innerhalb OPC UA standardisierten Informationen anbieten zu können. 
Das Interesse der IT-Welt ist unglaublich groß und somit wird sich OPC UA mit seinen Schnittstellen REST und OPC UA over MQTT in Zukunft noch sehr viel stärker in der IT-Welt etablieren. Erste Open-Source-Frameworks für Digitale Zwillinge und Metaverse gibt es bereits auf Basis von OPC UA, 
angeboten von Konsortien wie beispielswesie dem Digital Twin Consortium. Kurz: OPC UA hat das Potenzial sich sehr stark auch in der IT-Welt zu etablieren. Dieser Ausblick muss einfach motivieren!