OPC-UA in der Praxis: Das Protokoll für Maschinendaten
Symbolbild, KI-generiert (gpt-image-1)
OPC-UA ist der Standard, über den Maschinen ihre Daten herstellerübergreifend herausgeben — genormt als IEC 62541. Wer Maschinendaten braucht, landet früher oder später bei diesem Protokoll, meist nachdem der Weg über digitale Ausgänge und Modbus an seine Grenze gekommen ist. Die Frage ist deshalb selten „OPC-UA ja oder nein", sondern: An welcher Stelle lohnt der Sprung, und was kostet er im Betrieb?
Das Prinzip: Der Wert bringt seine Bedeutung mit
Ein Modbus-Register liefert eine Zahl. Was diese Zahl bedeutet, steht in einer
Excel-Tabelle, die der Inbetriebnehmer geschrieben hat und die niemand mehr findet — Register
40001, Wert 1200, Einheit unbekannt. Bei OPC-UA hängt am selben Wert der Name
Vorschubgeschwindigkeit, der Datentyp, die Einheit mm/min und der zulässige Bereich.
Der Unterschied ist derselbe wie zwischen einer Liste von Telefonnummern und einem Adressbuch. Beide enthalten dieselben Ziffern; nur eines davon kann man ohne den Autor benutzen. Das Informationsmodell ist der eigentliche Gegenstand von OPC-UA — die Datenübertragung ist der einfachere Teil.
Stufe 1: Für „läuft / läuft nicht" reicht eine Klemme
Soll nur erfasst werden, ob eine Maschine produziert, steht, oder gestört ist, braucht es kein Protokoll. Ein digitaler Ausgang auf einen Eingang des Gateways, fertig. Das ist robust, kostet nichts und fällt nicht aus, wenn jemand die Firmware der Steuerung tauscht.
Die Stufe endet, sobald man Werte statt Zustände braucht.
Stufe 2: Modbus TCP, solange die Liste kurz bleibt
Für zwanzig Messwerte aus einer Steuerung ist Modbus TCP nach wie vor eine vernünftige Antwort. Es ist in praktisch jeder Steuerung vorhanden, in einer Stunde eingerichtet und braucht auf dem Gateway kaum Ressourcen.
Der Bruch kommt nicht bei der Technik, sondern bei der Pflege: Werden es zweihundert Werte, kommen neue Maschinentypen dazu oder wechselt der Zulieferer, ist die Registertabelle das Problem. Jede Maschine bekommt eine eigene, keine gleicht der anderen, und die Zuordnung lebt in einem Dokument statt im System. Wächst der Bestand, wächst dieser Aufwand linear mit — und niemand hat ihn eingeplant.
Stufe 3: OPC-UA, sobald mehrere Maschinentypen zusammenkommen
Hier zahlt sich das Informationsmodell aus. Ein Client verbindet sich auf den Server der Maschine, liest den Adressraum aus und weiß, was dort steht — ohne Registertabelle. Kommt eine Maschine desselben Typs dazu, funktioniert derselbe Client ohne Anpassung.
Der Hebel liegt in den Companion Specifications: branchenspezifische Modelle, die festlegen, wie eine Werkzeugmaschine oder ein Robotersystem ihre Daten zu benennen hat. Halten sich zwei Hersteller an dieselbe Spezifikation, spricht ihre Maschine dieselbe Sprache. Halten sie sich nicht daran — und das kommt vor —, hat man OPC-UA mit dem Pflegeaufwand von Modbus.
Fragen Sie deshalb bei der Beschaffung nicht, ob die Maschine OPC-UA kann, sondern welcher Companion Specification ihr Modell folgt. Die erste Frage beantwortet jeder Vertrieb mit ja.
Stufe 4: Sollen viele Empfänger dieselben Daten sehen, wird es PubSub
Client/Server ist eine Punkt-zu-Punkt-Beziehung: Jeder Interessent baut seine eigene Verbindung auf. Bei drei Empfängern ist das egal, bei dreißig nicht mehr. Für diesen Fall gibt es OPC-UA PubSub sowie den pragmatischeren Weg, die Werte über MQTT zu verteilen — ein Gateway liest per OPC-UA aus der Maschine und veröffentlicht in ein Topic, aus dem sich alle weiteren Systeme bedienen. Wie das auf einem Router eingerichtet wird, steht in der Anleitung zu MQTT mit Teltonika-Routern.
Die Sicherheit ist eingebaut — und meistens ausgeschaltet
Die verbreitete Annahme lautet, OPC-UA sei sicher, weil Verschlüsselung und Zertifikatsprüfung zum Standard gehören. Das stimmt für die Spezifikation. Für die Anlage stimmt es nur, wenn jemand die Sicherheit eingeschaltet hat.
In der Praxis läuft ein erheblicher Teil der Server mit SecurityPolicy: None und anonymer
Anmeldung — nicht aus Nachlässigkeit, sondern weil es bei der Inbetriebnahme funktionieren
musste und niemand danach zurückgekommen ist. Der Grund ist fast immer derselbe: Die
Zertifikatsverwaltung ist der unangenehmste Teil des Protokolls. Zertifikate laufen ab,
Vertrauenslisten müssen auf beiden Seiten gepflegt werden, und ein abgelaufenes Zertifikat
sieht in der Diagnose aus wie ein Netzwerkfehler.
Wer OPC-UA einführt, plant die Zertifikatspflege als Betriebsaufgabe ein — sonst führt er Modbus mit mehr Schritten ein. Ein Ablaufdatum gehört in denselben Kalender wie die Wartungsintervalle.
Wie viele Werte trägt ein Gateway? Eine Rechnung
Zweihundert Variablen, alle 100 ms abgetastet, ergeben 2.000 Werte pro Sekunde. Bei grob 30 Byte je Wert samt Zeitstempel und Statuscode sind das rund 60 kB/s, also etwa 480 kbit/s — weniger als ein Videoanruf. Die Leitung ist also nie das Problem.
Die Grenze liegt woanders: Jeder Wert muss auf der Maschinenseite erzeugt, mit Zeitstempel versehen und in eine Benachrichtigung verpackt werden. Genau daran kommen kleine Steuerungen an ihr Ende, lange bevor das Netzwerk warm wird.
Zwei Konsequenzen folgen daraus. Erstens: Abonnements statt zyklischem Auslesen — der Server meldet Änderungen, statt zweihundertmal dieselbe Zahl zu schicken. Zweitens die Faustregel: Unterhalb von etwa 100 ms Zykluszeit gehört ein Wert nicht mehr auf OPC-UA, sondern in die Steuerung. Wer eine Regelung über das Protokoll schließen will, hat sich in der Ebene vertan; wer Prozesswerte erfassen will, hat reichlich Reserve.
Wo das Protokoll auf die Hardware trifft
Die Maschine spricht, jemand muss zuhören. Diese Rolle übernimmt in aller Regel ein Rechner im Schaltschrank, der die Daten einsammelt, puffert und weitergibt — bei ausgefallener Leitung eben auch für ein paar Stunden. Was ein solches Gerät ausmacht, steht im Artikel zum Edge-Computer; die Frage, was davon lokal verarbeitet und was weitergereicht wird, behandelt Edge AI vs. Cloud AI.
Die Anforderungen sind moderat — OPC-UA ist keine rechenintensive Angelegenheit. Zwei Dinge zählen trotzdem: genug Arbeitsspeicher für den Adressraum aller angebundenen Maschinen, und ein Dateisystem, das den Puffer aushält. Wird lokal auch noch ausgewertet, ändert sich das Bild, und die KI-Inferenz an der Anlage gibt die Auslegung vor.
Situation und Empfehlung
| Situation | Empfehlung |
|---|---|
| Nur Zustand „läuft / steht / gestört" | Digitaler Ausgang, kein Protokoll |
| Bis ~20 Werte, eine Maschine, ein Typ | Modbus TCP |
| Mehrere Maschinentypen, wachsender Bestand | OPC-UA |
| Maschine neu beschafft | Companion Specification vertraglich festhalten |
| Mehr als eine Handvoll Datenempfänger | OPC-UA auslesen, per MQTT verteilen |
| Zykluszeit unter 100 ms | Gehört in die Steuerung, nicht ins Protokoll |
| Anlage im Werksnetz erreichbar | Security einschalten, Zertifikatspflege terminieren |
Wer heute anfängt, beginnt bei der Beschaffung und nicht beim Gateway: Eine Maschine, deren Datenmodell einer Companion Specification folgt, spart über ihre Lebensdauer mehr Aufwand ein, als jede spätere Software-Anpassung wieder hereinholt.
Passende Hardware für die Datenerfassung an der Anlage: Box-PCs und Industrie-PCs, dazu Industrial-Ethernet-Switches für die Anbindung im Schaltschrank.
Zurück zum Wiki-Inhaltsverzeichnis.