OPC UA vs. MQTT – Wie bekommt man die Daten aus 100+ Maschinen?

Madeleine:

Hallo und willkommen, liebe Freunde des IoT. Das ist euer Podcast für die Umsetzung von IoT- und IIoT-Projekten in der Praxis. Ich bin euer Host, Madeleine Mickeleit, studierte Maschinenbauingenieurin, und viele von euch erzählen mir dasselbe: Eure Maschinen sind alt, stammen von vielen Herstellern, und jede spricht ihre eigene Sprache. Wie bekommt man die Daten also am besten raus?

Heute schauen wir uns ein echtes Kundenprojekt in Finnland an. Es gehört zu einer internationalen Fertigungsgruppe, und dort stehen mehr als 100 Maschinen in einem Werk, das über viele Jahrzehnte gewachsen ist. Das Team hatte eine große Frage: Wie können wir all diese Maschinendaten anbinden und bewegen? Und heute schauen wir uns im Podcast zum allerersten Mal MQTT versus OPC UA an. MQTT und OPC UA sind zwei großartige Wege, Maschinen anzubinden – aber welchen nutzt man wann? Und ist es wirklich das eine gegen das andere, oder kann man auch beides nutzen?

Pyry, mein heutiger Gast, hat dazu eine klare Meinung, und die könnte euch überraschen. Pyry Grönholm ist CEO von Prosys OPC. Er ist seit fast 30 Jahren in diesem Bereich unterwegs, ein absoluter Experte – es war eine tolle Session mit ihm. Wir hatten außerdem eine spannende Diskussion über KI: wie KI die Variablen einer neuen Maschine in eurer IoT-Plattform anlegen kann, damit ihr das nicht von Hand machen müsst. Pyrys Team hat das getestet, und er hat richtig spannende Einblicke dazu. Viel Spaß mit dieser Folge – let's go!

Hallo Pyry, willkommen in der Show. Schön, dass du da bist. Wie geht's dir heute? Und übrigens: Ich hoffe, ich habe deinen Namen richtig ausgesprochen.

Pyry:

Danke, Madeleine, ich freue mich sehr, hier zu sein. Und keine Sorge: Mein Name ist für Nicht-Finnen schwer auszusprechen, aber du machst das im Vergleich zu den meisten anderen richtig gut.

Madeleine:

Ich freue mich so, dass du heute im Podcast bist. Du bist CEO von Prosys OPC und absoluter Experte für IT/OT-Integration, außerdem für KI in der OT und OT-Security, natürlich für OPC UA und für MQTT. Ich freue mich also sehr, dich in dieser besonderen Folge dabeizuhaben. Wo bist du eigentlich ansässig? Du bist ja nicht in Deutschland, oder? Wo sitzt du gerade?

Pyry:

Prosys OPC ist ein finnisches Unternehmen. Wir sitzen in Espoo in Finnland, das liegt im Großraum Helsinki. Das ist sozusagen der Technologie-Hub Finnlands: viele kleine und große Unternehmen, vor allem aber die technischen Universitäten in der Nähe. Hier sitzen auch einige der derzeit meistgehypten finnischen Unternehmen, etwa ICEYE oder IQM.

Madeleine:

Dann ein Shout-out und viele Grüße an alle, die aus dieser Region zuhören – oder vielleicht hört ihr gerade im Auto zu, beim Sport, wo auch immer. Willkommen, und schön, dass ihr heute bei dieser Folge dabei seid. Für alle, die Prosys nicht kennen: Ihr seid ein führender Anbieter von OPC-UA- und OPC-Softwareprodukten, mit über 30 Jahren Erfahrung in diesem Bereich.

Pyry:

Ja, wenn ich darf, würde ich sagen: OPC UA ist die Kerntechnologie, die wir beherrschen. Aber letztlich ist OPC UA nur eine Technologie. Für sich genommen bringt sie den Kunden keinen Mehrwert – sondern erst, wenn man sie richtig einsetzt. Bei Prosys OPC versuchen wir, OPC UA, aber auch MQTT und andere Technologien so zu kombinieren, dass für die Endkunden die bestmögliche Lösung für ihre IT/OT-Integration entsteht. Im Kern geht es bei uns also um IT/OT-Integration – und gelöst wird sie natürlich mit OPC UA, wo es sinnvoll ist.

Madeleine:

Ja, wie du sagst: Es ist nur die Technologie, und dann geht es darum, was die Kunden damit machen und warum sie die Architektur für unterschiedliche Use Cases brauchen. Wenn wir über OT/IT-Datenintegration sprechen – du bist ja schon so lange in diesem Thema unterwegs. Du schreibst auch viel und veröffentlichst Blogposts, ich glaube fast alle paar Wochen. Ich würde gern von deiner Erfahrung lernen: Womit lagst du vielleicht am meisten daneben, was du in den letzten Jahren lernen oder auch wieder verlernen musstest?

Pyry:

Ich versuche immer, ganz vorne mit dabei zu sein. Wann immer etwas Neues kommt, versuche ich es zu verstehen. Und den Blog nutze ich auch, um mein eigenes Denken zu sortieren. Wenn man etwas unter dem eigenen Namen veröffentlicht, sorgt man dafür, dass es Qualität hat.

Madeleine:

Und womit lagst du damals vielleicht am meisten daneben?

Pyry:

Ich bin tatsächlich seit 29 Jahren im Unternehmen und habe als Trainee angefangen. Das war sehr praktisch: Unser Büro liegt nahe an der Universität, so konnte ich damals zwischen Büro und Uni hin- und herpendeln. Aber die Branche hat sich in diesen Jahren gar nicht so sehr verändert. Das Erste, was ich gemacht habe, war ein OEE-Reporting für eine Digitaldruckmaschine. Und heute – zum Beispiel in dem Case, den wir hier vorstellen – kommen wir immer noch auf dasselbe Thema zurück. Wir bauen wieder ein OEE-Reporting.

Wenn ich aber sagen müsste, womit ich und das ganze Unternehmen danebenlagen, dann war es immer die Geschwindigkeit, mit der neue Technologien in der Fertigung ankommen. Wir haben zum Beispiel fast 20 Jahre lang viel Arbeit in OPC UA gesteckt, aber ich glaube, erst jetzt bekommt es die Verbreitung, die es verdient.

Es gibt viele neue Technologien, die sehr gut sein könnten. Aber inzwischen habe ich wohl gelernt: Nicht zu schnell auf diese neuen Technologien setzen. Die Investitionszyklen in der Fertigung liegen bei etwa 20 Jahren. Neues wird dort nicht gerade mit offenen Armen empfangen, weil man alte Maschinen und Systeme ohnehin noch zehn Jahre oder so weiterbetreiben will.

Madeleine:

Ja, das deckt sich mit dem, was ich sehe. Ich bin jetzt seit etwa acht Jahren im Markt unterwegs, und auf dem Shopfloor hat sich die Konnektivität nicht so stark verändert. Aber jeden Monat drängen Anbieter mit neuen Produkten und neuen Buzzwords in den Markt. Was hat sich aus OT/IT-Sicht in den letzten Jahren aus deiner Sicht wirklich verändert, und was ist vielleicht nur ein neuer Name für eine alte Idee?

Pyry:

Na ja, an den neuen Buzzwords hänge ich mich immer noch ein bisschen auf. Und genau das meine ich: Ich habe gelernt, dass ein neues Buzzword noch lange nicht heißt, dass sich etwas leicht durchsetzt. Ich bin zum Beispiel gerade extrem begeistert vom Web of Things, weiß aber trotzdem, dass es noch einige Jahre dauern wird, bis es sich durchsetzt – wenn überhaupt. Unsere Produkte unterstützen es trotzdem schon, und es würde automatisiertes Asset-Onboarding ermöglichen. Das würde die IT/OT-Integration enorm beschleunigen.

Madeleine:

Du sprichst Web of Things an. Web of Things wird in vielen Bereichen verwendet, vom Smart Home bis zur Industrie, und ich höre dazu sehr unterschiedliche Definitionen. Was meinst du damit im industriellen Umfeld, und was ändert sich, wenn man zum Beispiel ein neues Gerät onboardet?

Pyry:

Web of Things ist tatsächlich ein Standard. Das heißt: Jedes Asset, das man ins Werk bringt, kommt mit einer sogenannten Thing Description. Das ist ein Informationsmodell plus Konfigurationsanweisungen für dieses Asset. Wenn man ein System hat wie unser Prosys Forge – es könnte aber jede Art von Client-Software in der IT/OT-Integration sein – und man diese Thing Description hochlädt und das System sie unterstützt, gibt man nur noch die IP-Adresse des Geräts ein, und es wird automatisch angebunden. Es legt also alle Variablen, den ganzen Kontext und die Konnektivität für das Gerät an. Es gibt bereits zumindest Siemens-Produkte, die mit einer Thing Description ausgeliefert werden.

Madeleine:

Das ist also das, was ich normalerweise manuell machen muss, zum Beispiel in meiner Asset-Management-Anwendung: Okay, ich habe einen neuen Sensor, ein neues Gateway, was auch immer. Dann muss ich all das machen, was du erwähnst, alle Variablen eintragen. Diese ganze manuelle Arbeit wäre also nicht mehr nötig, weil ich dieses Feature habe.

Pyry:

Genau. Und ziemlich häufig, etwa bei einem Modbus-Gerät, gibt es gar keine Variablennamen, sondern nur Register – im Grunde Register 1, 2, 3, 4, 5. Die Thing Description sagt einem dann für jedes Register, wie die Variable heißt, was der eigentliche Wert ist und welche Einheit er hat. In manchen Fällen muss man sogar angeben, ob in dem Register ein Integer, ein String oder ein Float steht, um es überhaupt nutzen zu können. Sie liefert also all diese Informationen. Statt in irgendwelchen Spezifikationen oder einer Excel-Liste nachzuschauen und das dann ins System abzutippen, erledigt sie diese ganze Arbeit automatisch.

Madeleine:

Verstehe, das ist ziemlich spannend. In Folge 242 sprechen wir mit Cumulocity über ein verwandtes Problem: Deren KI-Agent liest die Rohdaten eines neuen Geräts und schlägt das Mapping vor, sodass niemand es von Hand schreiben muss. Übrigens: Wer mehr darüber hören will, hört in Folge 242 rein und folgt diesem Podcast – es kommen noch mehr AIoT-Projekte und Kunden, die erzählen, wie sie es machen.

Aber zurück zum Thema. Du und dein Unternehmen arbeitet viel mit diesen offenen Informationsmodellen. Habt ihr bei Prosys KI dafür getestet? Und wenn ja, wie gut hat es funktioniert?

Pyry:

Ja. Man könnte KI nutzen, um diese Web-of-Things-Beschreibungen für die eigenen Assets zu erstellen. Man gibt ihr die Dokumentation, die man zu dem Asset hat, und sagt dann einfach: Hey, das ist der Standard, bitte erstell mir die JSON-Datei für das Asset. Die könnte man dann einfach hochladen, und das Asset wäre automatisch angebunden. In gewisser Weise kann man das also nutzen. Wir hatten im Unternehmen aber tatsächlich eine Masterarbeit zu genau dieser KI-gestützten Datenharmonisierung.

Madeleine:

Und was kam dabei raus?

Pyry:

Das Ergebnis war – zumindest mit den Modellen, die wir damals verwendet haben; das war vor einem halben Jahr, und das ist in der KI ja wie ein Jahrzehnt –, dass die Ergebnisse zu etwa 60, 70 % korrekt waren. Das hängt ein bisschen davon ab, wie man rechnet, denn wir haben sie kategorisiert: in die, bei denen wir sicher waren, die, die wahrscheinlich okay waren, und die, die höchstwahrscheinlich falsch waren. Das System hat also etwas automatisch gemappt und es dann dem Endanwender als Vorschlag gegeben: Kannst du prüfen, ob das korrekt ist? Und manche Variablen hat es komplett verworfen: Dazu finde ich nichts. Und zusammen damit – aber eben noch nicht perfekt.

Madeleine:

Klar, klar. Am Ende wird es neue und bessere Ergebnisse geben. Aber jetzt sind wir direkt bei neuen Themen gelandet – sehr spannend. Über euer Produkt Prosys Forge sprechen wir gleich noch. Und für alle, die gerade zuhören: Über OPC UA und MQTT sprechen wir auch gleich. Hast du ein Projekt, über das wir heute mehr aus der Praxis sprechen können? Kannst du uns die Ausgangslage schildern, damit wir verstehen, was dein Kunde macht?

Pyry:

Ja. Grundsätzlich sind unsere Kunden natürlich sehr unterschiedlich. Wir bedienen im Grunde alle Branchen, Prozess- und Fertigungsindustrie: die stark regulierte Pharmaindustrie, die etwas weniger regulierte Luftfahrt- und Verteidigungsindustrie, Lebensmittel und Getränke und ganz klassische Maschinenbauer.

Heute wollte ich aber über einen unserer jüngsten Cases sprechen. Den Namen des Endkunden kann ich leider nicht nennen, aber es ist ein Maschinenbauwerk in Finnland, das zu einer internationalen Fertigungsgruppe gehört. Diskrete Fertigung. Die Herausforderung war in diesem Fall, dass es eine ziemlich große Fabrik ist und der Maschinenpark sehr heterogen. Er ist über Jahrzehnte gewachsen, würde ich sagen. Es gibt dort Maschinen von mehreren Herstellern, die auch ganz unterschiedliche Dinge tun. Selbst die CNC-Maschinen stammen von verschiedenen Herstellern und aus verschiedenen Generationen.

Die Ausgangslage war folgende: Wir hatten Maschinen mit sehr guter und einfacher Konnektivität. Dann hatten wir Maschinen, die nicht direkt angebunden waren, bei denen sich aber leicht ein Weg finden ließ, sie anzubinden. Und dann gab es Maschinen, die quasi abgeschrieben waren – bei denen haben wir einfach keine vernünftige Konnektivität hinbekommen, zumindest nicht in der ersten Phase.

Madeleine:

Okay. Hast du Beispiele, welche Hersteller das sind und um welche Art von Maschinen es geht? Größere Maschinen, kleinere Maschinen?

Pyry:

Na ja, zu den Herstellernamen möchte ich lieber nicht zu viel sagen.

Madeleine:

Die typischen eben: Honeywell, Siemens, WAGO, you name it, ifm-Sensoren.

Pyry:

Die CNC-Maschinen basierten größtenteils auf SINUMERIK. Der eigentliche Hersteller konnte ein anderer sein, aber angebunden wurde meistens die SINUMERIK. Es gab aber alle möglichen Maschinentypen: Schneiden, Schweißen, Pressen, auch Lackieren – insgesamt mehr als 100 Maschinen.

Madeleine:

Okay.

Pyry:

Ganz schön viele. Und ehrlich gesagt habe ich sie nicht alle gesehen. Aber am wertvollsten waren natürlich die CNC-Maschinen, auf die haben wir uns auch stark konzentriert. Wichtig waren auch die Pressen, und zwar im Hinblick auf OEE – das war der Ausgangspunkt des Projekts.

Madeleine:

Verstehe. OEE war also das erste Projekt, mit dem ihr bei ihnen angefangen habt?

Pyry:

Das war der Ausgangspunkt. Der eigentliche Auslöser, warum sie mit uns arbeiten wollten, war, dass sie wussten: In ein paar Jahren startet das neue MES-Projekt – eigentlich sogar früher, in zwei Jahren. Gleichzeitig war ihnen klar, dass sie nicht einmal ein richtig gutes Verständnis ihrer Konnektivität hatten. Und selbst wenn, wussten sie, dass nicht alle Maschinen die nötige Konnektivität haben.

Was wir also zuerst aufgebaut haben – mit Prosys Forge hat man eine Plattform, in die man die Daten aller Maschinen bringt. Dann harmonisiert man die Daten mithilfe von OPC-UA-Informationsmodellen. Und dann öffnet man die verschiedenen IT-Protokolle – natürlich kann auch OPC UA genutzt werden, so wie es in Richtung MES der Fall sein wird, aber für andere Systeme nimmt man dann REST oder MQTT oder was auch immer. Jedenfalls hatten sie das Gefühl, sich irgendwie vorbereiten zu müssen, damit das künftige MES-Projekt reibungslos läuft. Aber dann haben wir angefangen, darüber nachzudenken: Okay, es ist sehr schwer, an der Konnektivität zu arbeiten, wenn man kein Projekt hat, in dem man auch etwas mit den Daten macht.

Madeleine:

Für den Business-Nutzen.

Pyry:

Ja, genau, den Nutzen. Deshalb haben wir dann erkannt, dass ihr altes OEE-System veraltet war und ihnen nicht die Daten lieferte, die sie sich gewünscht haben. Also haben wir vorgeschlagen: Wie wäre es, wenn wir ein OEE-System aufbauen, das das alte ersetzt und genauere und stärker standardisierte Daten liefert als das alte?

Außerdem haben sie uns gebeten, ein Dashboard aller angebundenen Geräte zu bauen, damit sie den aktuellen Status kennen – ob die Maschinen laufen, stehen oder gerade eine Störung haben – und dazu eine Art Trend der Status. Wer einen Teil des Werks verantwortet, sollte eine eigene Ansicht haben und sofort sehen können, wie es in der eigenen Abteilung läuft. So haben wir angefangen, und dann haben wir nach und nach die Maschinen an dieses System angebunden. Und sowohl für die OEE als auch für das Dashboard hatten wir ein Informationsmodell, ein OPC-UA-Informationsmodell, in das wir die Daten geschrieben und sie dann entweder in Power BI oder ins Grafana-Dashboard integriert haben.

Madeleine:

Das in euer Produkt zu bringen, Prosys Forge – das ist ein IT/OT-Produkt, würde ich sagen. Man kann also alle Geräte aus der OT anbinden und sie dann auf die nächste Ebene in die IT bringen. Warum habt ihr euch hier für OPC UA entschieden? Und was habt ihr mit Maschinen gemacht, die sich nicht so leicht anbinden lassen, zum Beispiel richtig alte Maschinen? Denn für alle, die auf dem Shopfloor arbeiten, ist es eine Herausforderung, die Daten rauszubekommen – vielleicht auch aus alten Maschinen, die nicht OPC-UA-fähig sind. Wie habt ihr das gelöst, und warum habt ihr euch für OPC UA entschieden? Waren auch andere Technologien im Spiel?

Pyry:

Der Kern von Prosys Forge ist ein OPC-UA-Server, aber es ist uns eigentlich egal, wie die Daten in Prosys Forge kommen. Wir können die herstellerspezifischen Protokolle nutzen, von denen wir eine große Bandbreite unterstützen. Und wer die Daten lieber per MQTT oder REST nutzen möchte, kann das völlig problemlos tun. Im Produkt selbst haben wir aber diese ISA-95-Baumstruktur des Werks und die Standard-Informationsmodelle für die verschiedenen Maschinen.

In diesem Fall gab es also ein Status-Informationsmodell, das für alle gleich war. Das OEE-Informationsmodell, ebenfalls für alle gleich. Und jetzt, wo wir in Richtung MES erweitern, bekommt jede Maschine zusätzlich das MES-Informationsmodell, das auch für jede Maschine gleich sein wird. Würden wir anfangen, etwa Qualitätsdaten zu speichern, sähe das natürlich für jede Maschine anders aus, und jeder Maschinentyp bräuchte ein eigenes Informationsmodell. Die Pressen haben schlicht völlig andere Variablen als die CNC-Maschinen, die kann man nicht in dasselbe Modell zwingen. Man könnte aber trotzdem ein Modell für alle Pressen und eines für alle CNC-Maschinen haben.

Wir sind einfach überzeugt, dass OPC UA einen offenen Standard für die Informationsmodellierung bietet. Und dann gehört das Modell tatsächlich dem Kunden selbst. Es ist kein proprietäres Modell, das man mietet, weil es in einem System steckt, in dem man zwar modellieren, das Modell aber weder herausnehmen noch woanders wiederverwenden kann. In unserem Fall könnten die Modelle tatsächlich herausgenommen und zum Beispiel direkt auf die SPS gebracht werden. Die Harmonisierung muss also gar nicht auf Edge-Ebene stattfinden – schon die SPS kann die Daten in OPC-UA-Informationsmodellen bereitstellen, zumindest Siemens- und Beckhoff-SPSen können das. Deshalb nutzen wir OPC UA in Forge für die Datenmodellierung – aber es geht dabei nicht um die Konnektivität.

In unserem Fall hatte das bestehende OEE-System bereits viele Gateways in der Fabrik installiert, die mit den SPSen ohne Konnektivität verdrahtet waren. Mit diesen Gateways haben wir dann per Modbus kommuniziert, und so konnten wir auch die Daten für die Basismodelle bekommen. Als dann das MES-Projekt anstand, hatten wir über diese Modbus-Gateways natürlich nicht genug Daten. Also haben sie überall, wo es möglich war, OPC-UA-Server gekauft. Wo das nicht möglich war, haben wir die direkten Siemens- oder Beckhoff-Konnektoren oder den EtherNet/IP-Konnektor genutzt. Ich glaube, Modbus lief nur über diese Gateways.

Und in manchen Fällen haben sie die SPSen tatsächlich ausgetauscht oder eine neue SPS neben die alte gesetzt. Dann haben sie einfach die Steuerungs-SPS mit der SPS für die Datenanbindung verdrahtet. Das waren mehr oder weniger die grundlegenden Wege, die Konnektivitätsprobleme zu lösen.

Madeleine:

Verstehe. In unserer Community nutzen natürlich viele MQTT. Sie setzen unterschiedliche Technologien ein. OPC UA ist ein etablierter Standard, würde ich sagen. Kann man also sagen: MQTT oder OPC UA, MQTT versus OPC UA – welches gewinnt eigentlich bei Industriedaten? Das ist ein bisschen provokant, aber was ich dahinter eigentlich fragen will: Gibt es für die verschiedenen Technologien jeweils einen bestimmten Use Case? Weißt du, was ich meine?

Pyry:

Ja, ich weiß, was du meinst. Weißt du, meine fünf Sekunden als LinkedIn-Star hatte ich, als ich vor vier, fünf Jahren einen Post „OPC UA versus MQTT oder OPC UA over MQTT“ geschrieben habe. Ich weiß nicht mehr, wie viele Impressions er bekommen hat, aber es waren jedenfalls so um die …

Madeleine:

Mehr als 100.000?

Pyry:

Mehr als 100.000, weit mehr. Das waren meine fünf Sekunden Ruhm. In meiner Welt sind beide Technologien großartig. Sie sind in gewisser Weise sehr unterschiedlich, und ich denke, sie sind für unterschiedliche Zwecke gemacht. OPC UA ist natürlich eine Architektur. Da ist alles enthalten: der Transport, die Informationsmodellierung, die Security. MQTT ist mehr oder weniger nur ein Transport. Wenn man MQTT nutzt, braucht man eine separate Vereinbarung zwischen Publisher und Subscriber darüber, wie die Payload aussieht.

Madeleine:

Mit Payload meinst du die Nutzdaten?

Pyry:

Die Payload kann einfacher Text sein, sie kann binär sein, JSON oder XML. Und das Schema der Payload muss zwischen Publisher und Subscriber ausgetauscht werden, sonst wartet der eine auf JSON, während der andere zum Beispiel XML schickt. Dann kann man die empfangenen Daten nicht interpretieren. Für MQTT gibt es Sparkplug B, das die Struktur bzw. die Payload standardisiert. Aber das hat wiederum andere Probleme – darauf gehe ich jetzt nicht zu sehr ein –, weshalb es sich nicht wirklich durchgesetzt hat. Ich habe zumindest das Gefühl, dass es gerade eher abwärts als aufwärts geht.

Außerdem hat OPC UA ein Verbindungsmonitoring und arbeitet mit Request-Response. Bei MQTT schickt man eher die Daten raus, und wenn man eine Antwort auf das Gesendete haben will, muss man die Logik dafür selbst bauen. Das ist im Protokoll nicht eingebaut – zumindest nicht in den Protokollversionen, die wir aktuell typischerweise sehen. Deshalb finde ich OPC UA sehr gut, wenn man nah an den SPSen ist, also auf der Steuerungsebene. Denn damit kann man sich tatsächlich sicher sein, dass das, was man angefordert hat, auch passiert ist. Man kann standardisiert modellieren, und es ist eher Plug-and-Play.

Wenn man dagegen Daten in die Cloud schicken muss, ist MQTT ziemlich leichtgewichtig. Es hat eine sehr gute Performance und funktioniert für diese Zwecke sehr gut. Und dann gibt es, wie gesagt, Sparkplug, aber natürlich auch OPC UA over MQTT. Das ist ein OPC-UA-Standard dafür, wie man OPC-UA-Payloads, OPC-UA-Topic-Trees und all das nutzt – und damit wird auch mit MQTT mehr von dieser Plug-and-Play-Konnektivität möglich.

Unser Standardansatz in Prosys Forge ist, glaube ich: Wenn wir an die Cloud anbinden, nutzen wir immer entweder MQTT oder AMQP – AMQP in manchen Fällen in Azure, weil Event Hubs günstiger ist und kein MQTT unterstützt, sondern nur AMQP. Als Protokolle sind die beiden aber sehr ähnlich. Ich glaube nicht, dass sie miteinander konkurrieren. Ich denke eher, dass es für unterschiedliche Protokolle unterschiedliche Use Cases gibt. Und es konkurrieren aktuell sogar noch mehr Protokolle als diese beiden.

Aber hey, eine Sache noch: Wer dieses Thema wirklich gut verstehen will – Matthew Parris schreibt auf LinkedIn eine Blogserie darüber, wie man über den Stellvertreterkrieg zwischen OPC UA und MQTT hinauskommt. Man braucht ein paar Stunden, um sich da durchzulesen, aber es ist eine sehr, sehr gut geschriebene Serie.

Madeleine:

Für alle, die Matthew Parris nicht kennen: Ich packe auch sein LinkedIn-Profil dazu. Er schreibt viel zu dem Thema, folgt ihm also, er hat viel dazu zu sagen. Aber ich vermute, viele Zuhörer sind nicht ganz so technisch unterwegs – und ehrlich gesagt hast du mich bei AMQP verloren und bei dem, was du mit Azure meinst. Damit kenne ich mich nicht aus, und ich weiß nicht, wie technisch wir hier werden sollten.

Ich möchte kurz einordnen, was ich bisher verstanden habe. Kann man sagen, MQTT funktioniert eher nach dem Prinzip „Senden und hoffen“? Man schickt es raus, und es eignet sich für Monitoring, für das Auslesen von Statusupdates. Das ist super: Es ist schnell, leichtgewichtig und skaliert auf Tausende Geräte. OPC UA dagegen ist mehr als nur senden und hoffen. Kann man das so sagen?

Pyry:

Bei OPC UA ist es eher so, wie wenn ich jetzt mit dir spreche: Ich sehe sofort, ob du mich gehört hast, und du antwortest mir. MQTT ist eher so, als würde man etwas auf LinkedIn posten. Man weiß, dass es auf LinkedIn ist, aber man weiß nicht, wer es liest. Man weiß also nicht, ob es je beim Publikum angekommen ist oder bei jemandem, den man eigentlich erreichen wollte – dafür ist es dann für alle leicht verfügbar und sehr leichtgewichtig. OPC UA ist also Punkt-zu-Punkt – du und ich –, während man es bei MQTT auf den Broker legt. Man weiß, dass es beim Broker angekommen ist, hat aber keine Ahnung, wer dem Broker eigentlich zuhört.

Madeleine:

Okay. Und vielleicht noch eine letzte Frage dazu, denn die OPC Foundation ist auch einer unserer Partner, und Stefan Hoppe ist der OPC-Foundation-Vertreter …

Pyry:

Der Präsident.

Madeleine:

Ja, der Präsident. Sie haben außerdem diese Cloud-Initiative mit einer Referenzarchitektur gestartet, mit vielen verschiedenen Bausteinen, an denen sie arbeiten – nicht nur am Transport, sondern auch daran, den Kontext der Informationen zu erhalten. Wenn man zum Beispiel eine CNC-Maschine hat, hat man den Kontext der verschiedenen Variablen, weißt du, was ich meine?

Pyry:

Variablen, ja.

Madeleine:

Variablen, die man zum Beispiel in Azure braucht, um eine saubere End-to-End-Kommunikation von der OT in die IT sicherzustellen. Wie würde OPC UA over MQTT das lösen? Ist das einer der Bausteine, an denen sie arbeiten? Nur damit wir hier ihr Statement auch richtig wiedergeben.

Pyry:

Das Gute – oder das Schöne – an OPC UA over MQTT ist natürlich, dass man das Informationsmodell, das man hatte, bis zu einem gewissen Grad erhalten kann. Man ist nicht verpflichtet, es tatsächlich zu nutzen. Man müsste es allerdings mit der sogenannten OPC UA Cloud Library kombinieren – aber jetzt wird es wieder sehr technisch. Zusammen ermöglichen diese beiden Standards unter dem OPC-UA-Dach, in der Cloud Digital Twins dessen zu erstellen, was man im Werk hat.

Im Werk laufen sehr kritische Prozesse, und man will nicht, dass da irgendjemand etwas durcheinanderbringt. Wenn man die Daten aus dem Werk nun eins zu eins – im selben Format und mit denselben Informationsmodellen – in die Cloud kopieren will, braucht man einen sehr leichtgewichtigen Weg, um die Daten einfach zu publishen. Wenn man also OPC UA over MQTT nutzt und in der Cloud dasselbe Informationsmodell hat wie im Werk – oder natürlich nur einen Teil davon, nur ein Gerät oder was auch immer –, dann kann man den Digital Twin so aufbauen, dass er genau so aussieht wie im Werk, und die Daten fließen schnell per MQTT zwischen diesen Instanzen.

Darauf kann man dann natürlich das ganze Cloud-Reporting, die Analytics, alles aufbauen. Aber statt dass die Daten nur heißen „diese Variable hat einen neuen Wert“, hat man den ganzen Kontext in der Cloud. Man hat sozusagen den Bauplan des Werks, in dem die Daten dann erscheinen.

Madeleine:

Ich finde es auch wichtig, auf den Use Case dahinter zu schauen. Wenn ich zum Beispiel ein einzelnes entferntes Asset habe, etwa eine Wasserpumpstation, ist es sinnvoll, direkt über OPC UA zu senden. Aber es geht um Skalierung, wenn man, keine Ahnung, 5.000 SPSen hat – oder wie bei dir hundert Maschinen; ich weiß nicht, wie viele SPSen in einer Fabrik stehen. Man muss also sicherstellen, dass die Datenübertragung zuverlässig ist, auch im Hinblick auf Security und Handhabbarkeit.

Pyry:

Ja, und genau das ist natürlich ein Vorteil von MQTT: Wenn man Daten einfach von der Edge, also zwischen OT und IT, nach oben schickt, braucht man keine Verbindung nach unten. Man kann also eine harte Firewall haben, die nach unten in die OT nichts öffnet – denn die ist nie sicher, wie du weißt: Da stehen all die Geräte, irgendetwas muss immer aktualisiert werden. Die muss man also wirklich schützen.

Mit MQTT geht es also nur in eine Richtung nach oben, aber nichts nach unten. Und für diesen Use Case ist MQTT sehr praktisch. Es ist einfach, das so aufzubauen bzw. das OT-Netzwerk zu schützen, während man es nutzt. Es ist leichtgewichtig, schnell, alles läuft reibungslos. Aber es hat die Probleme, die ich erwähnt habe: Man muss sich abstimmen – wenn man die Daten verschlüsselt, wie man es gemacht hat; beide Seiten müssen es wissen und so weiter.

Madeleine:

Ja. Übrigens: Wer das noch weiter diskutieren möchte, zum Beispiel auf Anwenderebene – wir haben auch unseren Anwenderkreis, der sich jeden Monat trifft. Dort geht es viel um Skalierung und Kosten und wie man das umsetzt. Wenn man zum Beispiel eine Lösung hat, die für drei Maschinen funktioniert, ist das gut – aber wie macht man das bei 300 oder 3.000 Maschinen? Wie funktioniert die Skalierung? Wenn ihr also gerade zuhört: Kommt gern in unseren Anwenderkreis. Und wer eher technische Fragen hat oder mehr darüber lernen möchte, wie IT/OT-Integration richtig funktioniert – deine Kontaktdaten könnte ich doch auch in die Shownotes packen, oder? Damit man dich erreichen kann.

Pyry:

Natürlich, ich diskutiere immer gern darüber. Und ich finde, dass all diese Gespräche immer großartig sind, weil ich nicht behaupte, immer recht zu haben. So lernt man und bekommt neue Ideen. Aus den LinkedIn-Diskussionen, an denen ich mich beteiligt habe, habe ich zum Beispiel viel gelernt. Sogar unsere Produkte wurden angepasst – die Feature-Roadmap wurde auf Basis dieser Diskussionen angepasst, weil mir klar wurde: Daran habe ich vorher nicht gedacht, und das ist wichtig.

Madeleine:

Du hast übrigens ein unglaubliches Netzwerk in den verschiedenen Standardisierungs-Communitys. Hast du Empfehlungen, wo du sagst: Leute, wenn ihr mehr darüber lernen oder auf dem Laufenden bleiben wollt, folgt diesen Leuten? Natürlich die OPC Foundation und all die anderen Foundations da draußen, nicht nur für MQTT, Modbus, was auch immer – aber hast du bestimmte Nischen-Communitys, die du uns empfehlen würdest?

Pyry:

Innerhalb der OPC Foundation lernt man viel, wenn man an den Events teilnimmt, etwa am Online-Event OPC Day International, das einmal im Jahr stattfindet. Ich verfolge außerdem die Open Industry 4.0 Alliance und CESMII in den USA. Und es gibt einige Discord-Gruppen, in denen ziemlich aktiv über diese Themen diskutiert wird. Manchmal sind die Diskussionen sogar ziemlich, sagen wir, angespannt – vor allem in letzter Zeit, oder in den vergangenen Jahren, beim Thema Unified Namespace im Vergleich zu OPC UA und bei diesen Diskussionen um OPC UA versus MQTT.

Aber ich glaube, selbst dort sind wir inzwischen weitergekommen: von der Ebene, auf der sie direkt miteinander konkurrieren, hin zu dem Verständnis, dass alles seinen Platz hat. Und vor allem, dass die OPC-UA-Informationsmodelle in der Industrie so einzigartig sind, dass niemand sonst so etwas hat. Sie sind wirklich das Herzstück von OPC UA. Und selbst wenn man einen anderen Transport nutzt, möchte man diese Informationsmodelle verwenden.

Madeleine:

Danke für die Empfehlungen, das ist perfekt. Und ich möchte euch auch alle zur SPS dieses Jahr in Nürnberg einladen. Kommt vorbei, wir machen ein Meetup – ich glaube, am Dienstag. Kommt also vorbei, und lasst uns vor Ort mit allen Partnern und Anwendern diskutieren. Und wer nicht vor Ort ist, mit dem können wir auch online sprechen. Meldet euch also gern über das Netzwerk, wir können helfen.

Pyry:

Ja, ich bin auch auf der SPS und versuche, auch zum Meetup zu kommen, falls mich dort jemand treffen will.

Madeleine:

Ja.

Pyry:

Ja, eigentlich wollte ich vorhin noch etwas zu dem Case sagen: Dort hatten wir ursprünglich geplant, MQTT zwischen Standort und Cloud zu nutzen. Aber es gab eher Gründe in der Organisation des Kunden – wir konnten MQTT jedenfalls nicht so einfach öffnen. Deshalb sind wir letztlich einen anderen Weg gegangen: Wir haben OPC UA Reverse Connect genutzt. Dabei verbindet sich der OPC-UA-Server am Standort mit dem Client in der Cloud. So konnten wir die Standard-OPC-UA-Verbindung nutzen und die Daten dann in den Cloud-Datenbanken und Datenquellen für das OEE-Reporting speichern. Aber selbst in diesem Fall war die erste Idee eigentlich, MQTT zu nutzen, weil es wahrscheinlich etwas praktischer gewesen wäre. Ich bin also nicht immer nur für OPC UA – man sollte es dort nutzen, wo es am besten passt.

Madeleine:

Klar. Okay, dann vielleicht eine der letzten beiden Fragen für heute. Jemand aus unserer Community sagt: Wenn man verschiedene Datenpunkte hat – zum Beispiel eine Temperatur oder die Frage, ob eine Korrelation mit anderen Datenpunkten wichtig ist –, dann liegt dieses Wissen beim Fachexperten, zum Beispiel in einer ganz anderen Abteilung als beim Data Engineer. Die Person, die den Datenpunkt versteht, sitzt also vielleicht in einer ganz anderen Abteilung als die Person, die die Daten-Pipeline baut. Wie schließt euer Modell, oder vielleicht ein offenes Informationsmodell, diese Lücke in der Praxis? Du erzählst ja gerade, wie Forge hier die IT/OT-Integration macht.

Pyry:

Ja, genau das ist das Problem, vor dem typischerweise alle stehen, wenn sie solche Projekte machen, etwa Analytics-Projekte oder was auch immer. Es gibt jede Menge Wissen – das verborgene, stille Wissen im Werk darüber, wie Dinge funktionieren, was relevant ist und was nicht. Der typische Ansatz ist nun, sich einfach mit den Datenquellen zu verbinden, alles in die Cloud zu publishen, und dann arbeitet irgendein Data Engineer mit den Daten, der nicht viel Ahnung von ihnen hat, sondern nur ein grobes Verständnis davon, woran er arbeitet. Und dieser Ansatz scheitert, würde ich sagen, immer wieder.

Bei Forge ist die ganze Idee, dass es ein Werkzeug ist, das vor Ort von den Automatisierungsingenieuren konfiguriert wird. Sie übernehmen die Modellierung und die Kontextualisierung, sie beschreiben die Temperatur: wo sie in die ISA-95-Hierarchie gehört, was der normale Wertebereich ist und welchen Bereich sie nicht verlassen sollte. Außerdem geben sie an, ob der Wert, den wir sehen, in Celsius, Kelvin oder Fahrenheit ist. Oder in manchen Fällen bekommt man den Wert gar nicht in einer für Menschen lesbaren Form, sondern zum Beispiel nur als Widerstand. Dann haben sie wahrscheinlich das Handbuch zur Hand und können in Forge die Umrechnung vom Widerstand in Celsius anlegen.

Und sobald der Kontext aufgebaut ist – und wenn man natürlich OPC UA Companion Specs nutzt, also die Standard-Informationsmodelle, die die Hersteller-Communitys für ihre Maschinen erstellen, hat man ein umfangreiches Dokument, das den Kontext für die Werte liefert –, wird die Arbeit des Data Engineers plötzlich viel einfacher. So versuchen wir, das zu lösen. Natürlich sollte es immer einen kurzen Draht zwischen dem Data Engineer und den Automatisierern geben, wann immer etwas ist.

Und wenn dieser Kontext da ist, ist es nicht nur für den Data Engineer einfacher, sondern auch für die KI. Denn wenn man KI an ein typisches Automatisierungssystem anschließt, versteht sie kein bisschen, was diese Variablen sind, etwa B200_PV. Was ist das? Was soll ich darunter verstehen?

Madeleine:

Klar, klar. Okay.

Pyry:

Aber sobald es in ein Informationsmodell eingebettet ist, das genau das sagt – das ist eine Druckmessung an diesem bestimmten Tank oder Rohr oder was auch immer, und was der Tank macht, welchen Zweck er im Prozess hat –, dann versteht auch die KI viel mehr und erzeugt etwas, das nützlich ist.

Madeleine:

Okay, cool. Wenn ihr also gerade zuhört und mehr über Forge erfahren wollt: Schaut gern auf die Website, schaut euch Forge an, und vielleicht könnt ihr eine kleine Demo buchen oder ein Meetup, bei dem ihr mehr darüber lernt. Denn Forge ist wirklich ein einzigartiges, großartiges Tool – wir haben in unserem Netzwerk nicht allzu viele, die sich so in der Praxis bewährt haben. Schaut es euch also an. Und es verbindet nicht nur OT und IT, sondern kann mehr, wie wir heute besprochen haben – auch mit den neuen Features, an denen ihr gerade arbeitet, etwa zur Datenharmonisierung und Ähnlichem. Es ist ein tolles Tool.

Und vielleicht die allerletzte Frage für heute: Mich interessieren immer die Learnings aus so einem Projekt, die andere Kunden mitnehmen können. Du hast heute ja schon viele Einblicke geteilt. Aber gab es Learnings aus diesem Projekt, die sogar dich überrascht haben? Etwas, womit auch der Kunde nicht gerechnet hat? Hast du da Einblicke?

Pyry:

Ich glaube, eines der Learnings war, dass das, was anfangs völlig unmöglich aussah, gar nicht unmöglich war. Ich würde sagen, im ersten Meeting – ich weiß nicht, wie optimistisch wir da eigentlich waren. Es war eher so: Hey, das wird eine Herausforderung, mal sehen, ob wir 30 % oder 50 % oder wie viel auch immer der Maschinen abdecken. Aber ich glaube, wir haben viel mehr geschafft als erwartet.

Ein zweites Learning: Bei so einem internationalen Fertigungsunternehmen habe ich zu lange gebraucht, um zu verstehen, wie deren IT und die Bereitstellung funktionieren. Ich glaube, wir haben ziemlich viel Zeit damit verbracht, auf alle möglichen virtuellen Maschinen, Berechtigungen und Ähnliches zu warten – einfach weil, sagen wir mal, unsere Organisation nicht wusste, an welchen Fäden man ziehen muss.

Madeleine:

Das ist also ein großes Thema: die IT-Governance.

Pyry:

Genau. Aber wir haben auch gelernt, dass es tatsächlich sehr gut skaliert. Inzwischen arbeiten sie selbst an der Konnektivität, und wir sind nicht vor Ort. Aber wann immer sie eine neue Maschine angebunden haben, dauert es weniger als eine Stunde, bis sie live ist – auf den Dashboards, in der OEE, in der MES-Kommunikation. Es kostet uns kaum Zeit, die Daten zu mappen und Neues zu veröffentlichen, weil alles bereitsteht, zum Beispiel die Templates. Man deployt einfach die Templates, macht das Mapping, und das war's. Es skaliert also. Und auch die Reportingsysteme sind so gebaut, dass die Maschinen dort automatisch erscheinen. Die ersten haben viel mehr Zeit gekostet als heute.

Madeleine:

Okay, okay. Danke, dass du diese Learnings geteilt hast. Und noch eine Zusatzfrage – ich weiß nicht, ob wir sie in den Podcast nehmen, aber vielleicht ist sie eine schöne Ergänzung. Wir hatten eine Diskussion über das Manufacturing Execution System. Viele haben natürlich MES-Systeme, um ihre Produktion in Echtzeit zu steuern und nachzuverfolgen. Das ist wirklich die Basis dessen, was wir seit Jahrzehnten in dieser Architektur machen, dem typischen Pyramidenmodell. Und wenn wir jetzt über KI sprechen, bringt das vielleicht all diese Datenquellen durcheinander, und die ganze Architektur wird eher zu einem Netz, in dem vielleicht jeder Datenpunkt mit jedem verbunden ist. Glaubst du, dass das MES in fünf, zehn Jahren verschwinden wird? Was denkst du?

Pyry:

Zunächst einmal, wie ich am Anfang gesagt habe: Die Investitionszyklen sind lang, und Dinge passieren einfach nicht schnell. Ich bin mir also sicher, dass es MES-Systeme, wie wir sie heute verstehen, auch in zehn oder 20 Jahren noch geben wird. Es laufen jede Menge MES-Projekte mit den aktuellen Marktführern, die ich kenne, und ich weiß, dass die Idee ist, sie ab Fertigstellung 20 Jahre lang zu betreiben. Das MES verschwindet also nicht so schnell.

Aber ich verstehe die Frage, und ich verstehe die Diskussion. Ich hatte dazu erst kürzlich auch eine sehr schöne Diskussion auf LinkedIn. Jemand hat behauptet, das MES sei tot – und ist dann in seinem Post eigentlich ein Stück zu den Grundlagen zurückgekehrt: dass es das wohl doch nicht ist.

Ich sehe das so: Ich bezweifle, dass es in Zukunft keine MES-Systeme mehr geben wird. Ich glaube, es wird etwas geben, das wir immer noch MES nennen. Aber die heutigen Top-Produkte sind zu geschlossen, zu monolithisch und zu schwer zu konfigurieren. Und KI, die offenen Informationsmodelle und die neue Konnektivität werden das definitiv aufmischen. Sie werden auch die Aufgaben aufteilen. Ein MES macht typischerweise viel mehr als das grundlegende Job-Management und die Auftragssteuerung, die seine Kernaufgabe sind: den Shopfloor orchestrieren – was jede Maschine als Nächstes tun soll – und dann die Daten darüber speichern, was gemacht wurde, wie die Qualität war und so weiter. Und es wird neue Produkte geben, die zum Beispiel die Optimierung übernehmen, Track & Trace, die Instandhaltungsthemen und so weiter. Und ich glaube, selbst die alten Systeme müssen sich, wie soll ich sagen, modernisieren, um in zehn Jahren noch Marktführer zu sein.

Madeleine:

Okay, das ist eine ziemlich gute Antwort. Und vielleicht ist meine nächste Frage an die KI, wenn wir nach unserer Session Claude fragen: Wie würdest du eine Zero-Touch-Fabrik bauen, und worauf würdest du achten? Und ich vermute, das offene Informationsmodell wird einer dieser Punkte sein.

Pyry:

Genau.

Madeleine:

Es gibt noch weitere Aspekte dazu, aber das greife ich in meiner nächsten Folge auf.

Pyry:

Wenn ich das Thema frei wählen darf, zum Beispiel für Vorträge vor Studierenden, spreche ich immer über meine Traumwelt: Man bringt etwas Neues in die Fabrik, alles wird automatisch konfiguriert, jeder weiß, wie man es erkennt, und alles funktioniert perfekt. Also wirklich so, wie wenn man eine Maus an den Computer anschließt.

Madeleine:

Klar, das stimmt. Okay, dann danke für unsere Session heute. Es war mir eine Freude, dich hier im Podcast zu haben. Wir haben das Thema sehr praxisnah besprochen. Danke, dass du heute das Kundenprojekt unter NDA möglich gemacht hast, und auch für deine sehr konkreten, besonderen Antworten. Ich sorge dafür, dass es auf unserer Website auch eine Zusammenfassung gibt. Und damit überlasse ich dir das letzte Wort. Von meiner Seite: Danke, dass du in der Show warst, und bis zum nächsten Mal vielleicht.

Pyry:

Ja, danke dir, Madeleine. Es war mir wirklich eine Freude. Seit du angefangen hast – ich glaube, wir haben uns ziemlich früh auf LinkedIn vernetzt –, stand es, wenn nicht auf meiner Bucket List, dann doch fast darauf, einmal in einem Podcast mit dir zu sein. Und jetzt hat es geklappt.

Madeleine:

Perfekt. Danke dir und noch eine schöne restliche Woche. Tschüss!

Pyry:

Ja, danke. Tschüss!