15 Oktober 2026

OPC UA steht für OPC Unified Architecture und bezeichnet eine standardisierte Architektur für den industriellen Informationsaustausch. Sie verbindet Kommunikationsdienste mit der strukturierten Beschreibung von Daten und ihren Beziehungen. Dadurch können Maschinen und Anwendungen Informationen über Hersteller- und Plattformgrenzen hinweg austauschen. Welche Funktionen tatsächlich nutzbar sind, hängt von den unterstützten Profilen, Informationsmodellen und der konkreten Implementierung ab.

Welche Aufgabe erfüllt OPC UA?

In einer Produktion müssen unterschiedliche Systeme zusammenarbeiten: Steuerungen, Maschinen, Leitsysteme und übergeordnete Anwendungen. OPC UA stellt dafür gemeinsame technische Grundlagen bereit. Die Spezifikationen werden von der OPC Foundation gepflegt und sind auch in der Normenreihe IEC 62541 abgebildet.

Der Ansatz umfasst mehr als die Übertragung einzelner Zahlen. Informationen können als Objekte, Eigenschaften und Beziehungen dargestellt werden. Ein Empfänger kann dadurch beispielsweise erkennen, dass ein Messwert zu einer bestimmten Komponente gehört. Die fachliche Bedeutung muss dennoch passend modelliert und unterstützt sein.

Client-Server und PubSub

Kommunikationsmodell	Grundprinzip	Typische Einordnung
Client-Server	Ein Client nutzt angebotene Dienste eines Servers.	Informationen erkunden, Werte lesen oder Änderungen abonnieren
Publish-Subscribe	Ein Publisher stellt Daten bereit, die interessierte Subscriber empfangen.	Daten an mehrere Empfänger verteilen

Ein Server kann beispielsweise in einer Maschine oder einem Gateway bereitgestellt werden. Ein Client in einem MES liest die benötigten Informationen oder richtet eine Subscription ein. Dabei werden Änderungen gemäß den vereinbarten Einstellungen übertragen. Die tatsächlich verfügbaren Dienste müssen vom Produkt unterstützt und entsprechend berechtigt sein.

OPC UA PubSub beschreibt ein anderes Kommunikationsmuster. Die Spezifikation unterscheidet unter anderem brokerbasierte und brokerlose Varianten. MQTT kann dabei als Transportmechanismus eingesetzt werden. OPC UA und MQTT sind deshalb nicht grundsätzlich konkurrierende Alternativen; sie können in einer Architektur zusammenwirken.

Was ist ein Informationsmodell?

Ein Informationsmodell beschreibt die Struktur und Bedeutung angebotener Informationen. Statt nur eine Liste unkommentierter Variablen zu liefern, kann eine Maschine beispielsweise ihre Identifikation, Komponenten und Zustände geordnet darstellen. Typdefinitionen und Beziehungen ermöglichen eine wiederverwendbare Beschreibung.

Companion Specifications ergänzen den allgemeinen Rahmen um fachliche Modelle für bestimmte Bereiche. Sie können etwa gemeinsame Begriffe und Strukturen für Maschinentypen festlegen. Das reduziert individuelle Übersetzungen, sofern die beteiligten Produkte die benötigten Teile tatsächlich unterstützen.

Eine Companion Specification enthält gegebenenfalls optionale Elemente. Daher reicht die allgemeine Aussage, ein Produkt unterstütze das Modell, nicht immer aus. Für einen Anwendungsfall müssen benötigte Objekte, Eigenschaften und Funktionen konkret benannt werden.

Wert, Zeitstempel und Status

Ein übertragener Wert allein ist oft unzureichend. OPC UA kennt bei einem DataValue neben dem Wert auch einen Status und Zeitstempel. Die Spezifikation unterscheidet unter anderem den Zeitbezug der Quelle von dem des Servers. Damit kann eine Anwendung beurteilen, ob sie einen aktuellen und verwendbaren Wert erhalten hat.

Ein fehlerhafter Status darf nicht ignoriert werden, nur weil daneben noch eine Zahl steht. Ebenso ist ein alter Wert nicht automatisch eine aktuelle Beobachtung. Für Datenqualität müssen Empfänger die Zusatzinformationen passend berücksichtigen.

Auch Einheit und fachlicher Bezug sind wichtig. Der Zahlenwert 80 kann ohne Kontext eine Temperatur, einen Prozentwert oder eine Anzahl beschreiben. Die Übertragung schafft erst dann eine nutzbare Information, wenn die beteiligten Systeme dieselbe Bedeutung verwenden.

Praxisbeispiel: Maschine an ein MES anbinden

Das folgende Beispiel ist fiktiv. Ein Betrieb möchte von einer Maschine deren Betriebszustand, aktuelle Auftragskennung und gefertigte Menge an ein MES übergeben. Die Maschine bietet einen OPC-UA-Server an. Damit ist zunächst ein technischer Zugang vorhanden.

Bei der fachlichen Prüfung zeigt sich, dass der Mengenwert ein kumulativer Gesamtzähler ist. Das MES benötigt dagegen die auftragsbezogene Gutmenge. Zusätzlich fehlen am Maschinenzähler Angaben darüber, welche Teile später als Ausschuss eingestuft werden. Eine direkte Übernahme würde daher eine falsche Aussage erzeugen.

Die Integration legt deshalb fest, wie Auftragswechsel, Zählerstände und Qualitätsrückmeldungen zusammengeführt werden. Ein Zählerwechsel oder Rücksetzen erhält eine definierte Behandlung. Die Schnittstelle wird mit Normalbetrieb, Unterbrechung und Wiederanlauf geprüft. OPC UA transportiert und strukturiert die Informationen; die betriebliche Zuordnung bleibt eine konkrete Integrationsaufgabe.

Das Beispiel verdeutlicht Interoperabilität: Eine Verbindung kann technisch funktionieren, während für die gewünschte Zusammenarbeit noch fachliche Regeln fehlen.

Was gehört ins Lastenheft?

Ein Lastenheft sollte den benötigten Informationsaustausch konkret beschreiben. Die kurze Anforderung „OPC UA vorhanden“ lässt wichtige Fragen offen.

Benötigte Daten und ihre fachliche Bedeutung.
Unterstützte Informationsmodelle, Profile und Versionen.
Erforderliche Lese-, Schreib-, Ereignis- oder Methodenfunktionen.
Aktualisierung, Zeitstempel und Behandlung ungültiger Werte.
Verhalten bei Verbindungsverlust und Wiederanlauf.
Berechtigungen, Zertifikatsbetrieb und Zuständigkeiten.
Prüffälle für die vorgesehene Anwendung.

Schreibzugriffe und Methodenaufrufe können reale Auswirkungen auf die Maschine haben. Sie sollten deshalb getrennt von einer reinen Datenerfassung spezifiziert und geprüft werden. Eine Leseschnittstelle begründet keine automatische Freigabe für Prozessänderungen.

Sicherheit und Betriebsfähigkeit

OPC UA bietet Sicherheitsmechanismen, deren Wirksamkeit von Auswahl, Konfiguration und Betrieb abhängt. Dazu gehören bei geeigneten Kommunikationsformen beispielsweise Authentifizierung, Signierung und Verschlüsselung. Die bloße Produktbezeichnung garantiert keine angemessene Absicherung einer konkreten Verbindung.

Im Betrieb müssen unter anderem Vertrauensbeziehungen, Zertifikate und Zugriffsrechte gepflegt werden. Zuständigkeiten sind wichtig, damit ein ablaufendes Zertifikat nicht unerwartet die Datenversorgung unterbricht. Sicherheitsfunktionen sollten nicht zur schnellen Fehlerbehebung dauerhaft umgangen werden; stattdessen ist die konkrete Ursache zu bearbeiten.

Ein normales OPC-UA-Datenangebot ist außerdem kein pauschaler Nachweis harter Echtzeitfähigkeit oder funktionaler Sicherheit. Solche Anforderungen benötigen passende technische Ausprägungen und eigene Nachweise. Die allgemeine Architekturbezeichnung genügt dafür nicht.

Grenzen und Integrationsaufwand

Bei Bestandsmaschinen kann ein Gateway zusätzliche Daten bereitstellen. Es kann jedoch fehlende Informationen nicht zuverlässig erfinden. Wenn die Quelle keine Auftragskennung kennt, muss diese aus einem anderen geeigneten Zusammenhang kommen.

Auch Standardisierung beseitigt nicht jede Anpassung. Unterschiedliche Modellstände oder herstellerspezifische Erweiterungen können zusätzliche Arbeit verursachen. Eine dokumentierte Schnittstelle und passende Tests erleichtern spätere Änderungen. Für Maschinendatenerfassung ist deshalb die langfristige Pflege genauso zu berücksichtigen wie die erstmalige Verbindung.

Häufige Fragen zu OPC UA

Ist OPC UA nur ein Kommunikationsprotokoll?

Der Begriff umfasst mehr als einen einzelnen Übertragungsmechanismus. OPC UA beschreibt Dienste, Informationsmodelle und weitere Architekturbausteine. Für eine Anwendung sind sowohl Kommunikation als auch Datenbedeutung relevant. Deshalb sollte bei einer Schnittstellenbeschreibung konkret angegeben werden, welche Funktionen und Modelle unterstützt werden und welche Informationen der Empfänger tatsächlich nutzen kann.

Ersetzt OPC UA jede individuelle Schnittstellenarbeit?

Nein. Gemeinsame Modelle können den Aufwand reduzieren, aber der konkrete Anwendungsfall muss weiterhin abgestimmt werden. Dazu gehören Auftragsbezug, Mengendefinitionen und Fehlerverhalten. Optionale Funktionen oder unterschiedliche Implementierungen können zusätzliche Anpassungen erfordern. Ein erfolgreicher Verbindungstest allein belegt noch nicht den vollständig funktionierenden Produktionsablauf.

Was ist eine Companion Specification?

Sie beschreibt ein ergänzendes Informationsmodell für einen fachlichen Bereich auf Grundlage von OPC UA. Dadurch können Anbieter und Nutzer gemeinsame Strukturen und Begriffe verwenden. Welche Teile verbindlich oder optional sind, hängt von der jeweiligen Spezifikation ab. Für die Beschaffung sollten deshalb die tatsächlich benötigten Inhalte ausdrücklich vereinbart werden.

Kann OPC UA zusammen mit MQTT eingesetzt werden?

Ja. OPC UA PubSub kann MQTT als Transport nutzen. Dabei sind das transportierte Informationsmodell und der Nachrichtenweg unterschiedliche Aspekte der Architektur. Welche Kombination geeignet ist, hängt von den Anforderungen ab. Die Verwendung beider Namen allein sagt noch nichts über die tatsächlich unterstützten Profile, Sicherheitsmechanismen oder Dateninhalte aus.

Ist jede OPC-UA-Verbindung automatisch sicher?

Nein. Vorhandene Sicherheitsmechanismen müssen passend eingesetzt und betrieben werden. Berechtigungen, Vertrauensbeziehungen und die Pflege von Zertifikaten gehören zur Umsetzung. Außerdem bleibt die Einbindung in das gesamte Netz relevant. Die Sicherheit einer konkreten Anlage lässt sich nicht allein aus dem verwendeten Kommunikationsstandard ableiten.

Quellen und weiterführende Informationen

OPC Foundation: Unified Architecture, Architekturübersicht.
OPC Foundation: UA Companion Specifications.
OPC UA Part 4: DataValue, Werte, Status und Zeitstempel.
OPC UA Part 14: PubSub – Overview.

Stand: Oktober 2026. Das Integrationsbeispiel ist fiktiv.