Die OPC UA Interoperabilität Fertigung ist für Mittelständler mit heterogenem Maschinenpark längst kein Nischenthema mehr, denn ohne einen herstellerunabhängigen Kommunikationsstandard bleibt jede IoT-Initiative auf proprietäre Punkt-zu-Punkt-Anbindungen angewiesen. OPC Unified Architecture, kurz OPC UA und als IEC 62541 international genormt, verbindet Maschinensteuerungen, MES-Systeme, Cloud-Plattformen und Analysewerkzeuge über ein einheitliches Informationsmodell, das sowohl die reine Datenübertragung als auch deren semantische Bedeutung beschreibt. Im Unterschied zum älteren OPC-Classic-Standard, der auf der Windows-spezifischen DCOM-Technologie basierte, ist OPC UA plattformunabhängig, arbeitet über gängige Netzwerkprotokolle und bringt ein integriertes Sicherheitsmodell mit Zertifikaten und Verschlüsselung mit. Für produzierende Unternehmen im Mittelstand, die Sensorik, SPS-Ebene, MES und übergeordnete Cloud-Dienste schrittweise vernetzen, ist die Entscheidung für OPC UA meist der wirtschaftlich sinnvollste Weg, weil Maschinenbauer und Automatisierungsanbieter den Standard inzwischen breit unterstützen. Dieser Beitrag erläutert Architektur und Informationsmodell von OPC UA, ordnet die wichtigsten Companion Specifications ein und zeigt einen praxistauglichen Migrationspfad von bestehenden OPC-Classic- oder proprietären Schnittstellen.
Vom OPC-Classic-Standard zur Unified Architecture
OPC Classic, bestehend aus den Teilstandards DA (Data Access), AE (Alarms and Events) und HDA (Historical Data Access), war seit den 1990er-Jahren der De-facto-Standard für die Kommunikation zwischen SPS-Systemen und übergeordneten Softwaresystemen. Die technische Basis, Microsofts DCOM-Technologie, begrenzte den Einsatz jedoch auf Windows-Umgebungen und erschwerte die Kommunikation über Firewalls und Netzwerkgrenzen hinweg erheblich. Mit OPC UA hat die OPC Foundation ab 2006 einen vollständig neuen, plattformunabhängigen Standard geschaffen, der sowohl auf klassischen Client-Server-Verbindungen über TCP als auch, seit der Erweiterung um Teil 14, auf einem Publish-Subscribe-Modell (PubSub) über MQTT oder AMQP aufbaut.
Der wesentliche konzeptionelle Fortschritt liegt jedoch nicht in der reinen Transporttechnik, sondern im Informationsmodell. OPC UA überträgt nicht nur Rohwerte, sondern beschreibt deren Struktur, Typisierung und Beziehungen zueinander in einem objektorientierten Adressraum. Eine Temperaturmessung ist damit nicht mehr nur ein Zahlenwert an einer bestimmten Speicheradresse, sondern ein Knoten mit Einheit, Wertebereich, Zeitstempel, Qualitätsangabe und Verknüpfung zu übergeordneten Objekten wie einer Maschine oder Anlage.
Architektur und Informationsmodell im Überblick
Das OPC-UA-Adressraummodell besteht aus Knoten (Nodes) und Referenzen zwischen diesen Knoten. Jeder Knoten gehört zu einer von acht Basisklassen, darunter Objects, Variables, Methods und ObjectTypes. Referenzen wie „HasComponent“ oder „HasProperty“ bilden die semantischen Beziehungen zwischen Knoten ab und ermöglichen es einem Client, den Adressraum eines Servers zu durchsuchen (Browsing), ohne dessen Struktur vorab zu kennen. Diese Selbstbeschreibungsfähigkeit ist einer der zentralen Vorteile gegenüber proprietären Protokollen, bei denen jede Integration eine manuell gepflegte Mapping-Tabelle erfordert.
Server-Client-Modell und Publish-Subscribe
Im klassischen Server-Client-Modell stellt die Maschine oder Steuerung einen OPC-UA-Server bereit, auf den beliebig viele Clients, etwa ein MES oder ein Cloud-Gateway, zugreifen können. Für hochfrequente Sensordaten mit vielen angebundenen Abnehmern eignet sich seit einigen Jahren zusätzlich das PubSub-Modell, bei dem der Server Daten aktiv auf einen Nachrichtenbus wie MQTT veröffentlicht und interessierte Systeme sich als Abonnenten eintragen, ohne dass jede einzelne Verbindung individuell verwaltet werden muss. Für die meisten mittelständischen Anwendungen ist eine hybride Architektur sinnvoll: klassische Client-Server-Kommunikation für Konfigurations- und Steuerbefehle, PubSub für die kontinuierliche Übertragung von Prozess- und Zustandsdaten an Cloud-Plattformen.
Sicherheitsmodell mit Zertifikaten
OPC UA definiert in Teil 2 der Spezifikation ein vollständiges Sicherheitsmodell mit Authentifizierung, Autorisierung, Verschlüsselung und Signierung auf Basis von X.509-Zertifikaten. Anders als bei vielen älteren Industrieprotokollen ist Sicherheit damit kein nachträglich aufgesetztes Add-on, sondern integraler Bestandteil des Standards. In der Praxis bedeutet das jedoch auch einen nicht zu unterschätzenden Aufwand für Zertifikatsverwaltung, insbesondere beim Rollout über viele Maschinen und Standorte hinweg, wofür sich eine zentrale Public-Key-Infrastruktur oder ein spezialisiertes Zertifikatsmanagement-Tool empfiehlt.
Companion Specifications: Semantik über die Basisarchitektur hinaus
OPC UA allein definiert nur die technische Struktur des Informationsmodells, nicht jedoch, wie eine konkrete Maschine oder Baugruppe darin abgebildet wird. Diese Lücke schließen sogenannte Companion Specifications, die von Branchenverbänden gemeinsam mit der OPC Foundation entwickelt werden und standardisierte Informationsmodelle für bestimmte Maschinenklassen oder Anwendungsfälle festlegen. Für den Maschinen- und Anlagenbau sind insbesondere folgende Companion Specifications relevant:
- OPC UA for Machinery: ein branchenübergreifendes Basismodell für Maschinenidentifikation, Betriebszustände und Komponentenstruktur, entwickelt von VDMA und OPC Foundation.
- Euromap 77 und Euromap 83: Informationsmodelle für Kunststoff- und Gummimaschinen, die Prozessdaten und Auftragsinformationen standardisieren.
- OPC UA for Robotics: ein Modell für Industrierobotik mit standardisierten Bewegungs-, Programm- und Zustandsdaten.
- PackML/OMAC-Integration: ein Zustandsmodell für Verpackungsmaschinen, das Betriebsmodi und Ausfallursachen einheitlich beschreibt.
- OPC UA for CNC: ein Informationsmodell für Werkzeugmaschinen mit Bezug zu ISO 23247 (Digital Twin Framework for Manufacturing).
Der Einsatz einer passenden Companion Specification reduziert den Integrationsaufwand erheblich, weil MES- und Analysesysteme die semantische Bedeutung der Daten bereits kennen und nicht für jede Maschine neu interpretieren müssen. Fehlt eine passende Companion Specification für eine Maschinenklasse, empfiehlt sich die Anlehnung an das generische „OPC UA for Machinery“-Modell, statt ein vollständig proprietäres Informationsmodell zu entwerfen.
„OPC UA ist ein plattformunabhängiges, dienstorientiertes Architekturmodell, das Informationsmodellierung mit sicherer, zuverlässiger Kommunikation über verschiedene Transportprotokolle integriert.“ (sinngemäß nach der Definition der OPC Foundation zu IEC 62541)
Anbindung an MES, ERP und Cloud-Plattformen
Ein zentraler Praxisvorteil von OPC UA liegt in der strukturierten Anbindung an übergeordnete IT-Systeme. Da das Informationsmodell hierarchische Objektstrukturen abbildet, lässt es sich vergleichsweise direkt auf das ISA-95-Referenzmodell für die Fertigungssteuerung projizieren, das Ebenen von der Feldgeräte- bis zur Unternehmensebene definiert. MES-Anbieter bieten heute überwiegend native OPC-UA-Konnektoren an, sodass Auftrags-, Betriebs- und Qualitätsdaten ohne kundenspezifische Middleware ausgetauscht werden können. Für die Cloud-Anbindung nutzen die großen Hyperscaler eigene OPC-UA-kompatible Gateways: Microsoft Azure IoT bietet mit dem OPC Publisher eine containerisierte Komponente, die OPC-UA-Server ausliest und Daten per PubSub an Azure IoT Hub weiterleitet, während AWS IoT SiteWise über einen vergleichbaren Gateway-Ansatz verfügt.
Für die Digitalisierung eines Maschinenparks ist es sinnvoll, die OPC-UA-Anbindung nicht isoliert je Maschine zu planen, sondern ein unternehmensweites Informationsmodell zu definieren, das sich an einer Companion Specification orientiert und in dem neue Maschinen nach einem festen Muster eingebunden werden. Das folgende Beispiel zeigt eine vereinfachte Gegenüberstellung gängiger Kommunikationsansätze in der Fertigung.
| Ansatz | Plattformunabhängigkeit | Semantisches Informationsmodell | Integriertes Sicherheitsmodell |
|---|---|---|---|
| OPC Classic (DA/AE/HDA) | Nein, DCOM-basiert | Nein | Nein |
| Proprietäres Herstellerprotokoll | Herstellerabhängig | Nein | Herstellerabhängig |
| Modbus TCP | Ja | Nein | Nein |
| OPC UA | Ja | Ja, über Companion Specifications | Ja, X.509-basiert |
Migrationspfad von bestehenden Schnittstellen
Für Unternehmen mit gewachsenem Maschinenpark stellt sich selten die Frage einer vollständigen Neuinstallation, sondern eines schrittweisen Übergangs. Ein strukturierter Migrationspfad reduziert Risiken und Investitionsaufwand gleichermaßen.
- Bestandsaufnahme aller vorhandenen Schnittstellen je Maschine, einschließlich Protokoll, Datenpunkten und bestehender Integrationen.
- Auswahl einer passenden Companion Specification oder, falls keine existiert, Entwurf eines eigenen, an „OPC UA for Machinery“ angelehnten Informationsmodells.
- Einsatz von OPC-UA-Wrappern oder Gateways für Bestandsmaschinen ohne native OPC-UA-Unterstützung, die Modbus-, Profinet- oder herstellerspezifische Signale in einen OPC-UA-Adressraum übersetzen.
- Aufbau einer zentralen Zertifikatsverwaltung, bevor die erste produktive Maschine angebunden wird, um spätere Nacharbeiten zu vermeiden.
- Pilotierung an einer überschaubaren Anlagengruppe mit paralleler Validierung gegen die bisherige Schnittstelle, bevor die Migration auf den gesamten Maschinenpark ausgeweitet wird.
- Zertifizierung der eigenen Serverimplementierung über das OPC Foundation Compliance Test Tool (CTT), sofern eine eigene Serverentwicklung erfolgt, um Interoperabilität mit Drittsystemen sicherzustellen.
Typische Stolperfallen bei der Einführung
Adressraum ohne semantischen Standard
Wird der OPC-UA-Adressraum ohne Rückgriff auf eine Companion Specification frei modelliert, entsteht faktisch ein neues proprietäres Datenmodell, nur eben auf Basis von OPC UA transportiert. Der eigentliche Interoperabilitätsvorteil geht dadurch verloren, weil jedes anbindende System die individuelle Struktur erneut interpretieren muss.
Unterschätzter Aufwand für Zertifikatsmanagement
Gerade bei der Erstinbetriebnahme wird das Sicherheitsmodell häufig zunächst deaktiviert, um schneller Testdaten zu erhalten. In produktiven Umgebungen ist dieses Vorgehen jedoch riskant, da nachträgliche Aktivierung von Zertifikaten und Verschlüsselung über viele bereits verbundene Systeme hinweg deutlich aufwendiger ist als eine von Beginn an sichere Konfiguration.
Vermischung von PubSub und Client-Server ohne klare Architektur
Ohne klare Vorgaben, welche Datenkategorien über welches Kommunikationsmodell laufen, entstehen redundante Verbindungen und unnötige Netzwerklast. Eine dokumentierte Architekturentscheidung, welche Datenklassen per PubSub und welche per klassischem Client-Server-Zugriff übertragen werden, sollte deshalb vor dem Rollout stehen.
Namespace-Design und Versionierung des Informationsmodells
Ein häufig unterschätzter Aspekt bei der Einführung von OPC UA ist die saubere Verwaltung von Namespaces. Jeder Knoten im Adressraum gehört zu einem Namespace, identifiziert über eine Namespace-URI, die zwischen dem generischen OPC-UA-Basismodell, einer verwendeten Companion Specification und unternehmensspezifischen Erweiterungen unterscheidet. Werden unternehmensspezifische Datenpunkte ohne eigenen, klar dokumentierten Namespace direkt in den Adressraum einer Companion Specification eingemischt, wird die spätere Aktualisierung auf eine neue Version dieser Spezifikation unnötig kompliziert, weil sich Standard- und Eigenanteile nicht mehr sauber trennen lassen.
Für den produktiven Betrieb empfiehlt sich deshalb eine dreistufige Namespace-Struktur: ein Namespace für das OPC-UA-Basismodell, ein zweiter für die verwendete Companion Specification in ihrer jeweiligen Version und ein dritter, unternehmenseigener Namespace für Erweiterungen, die keine der beiden Standardebenen abdeckt. Diese Trennung erleichtert nicht nur Updates, sondern auch die spätere Migration einzelner Maschinen auf eine neue Companion-Specification-Version, da unternehmenseigene Erweiterungen unberührt bleiben.
Abgrenzung zu MQTT Sparkplug B und anderen IoT-Protokollen
In Digitalisierungsprojekten wird OPC UA gelegentlich mit reinen IoT-Messaging-Standards wie MQTT Sparkplug B verglichen oder sogar als konkurrierend wahrgenommen. Tatsächlich lösen beide Ansätze unterschiedliche Probleme: Sparkplug B definiert eine kompakte Nutzlaststruktur für MQTT-Nachrichten mit Fokus auf effiziente Zustandsübertragung, bringt jedoch kein vergleichbar umfassendes, objektorientiertes Informationsmodell mit Companion Specifications für konkrete Maschinenklassen mit. In vielen Architekturen werden beide Ansätze deshalb kombiniert: OPC UA übernimmt die semantische Modellierung auf Feldebene und in der Fabrik, während MQTT beziehungsweise OPC UA PubSub über MQTT als Transportschicht in Richtung Cloud fungiert. Für Unternehmen, die branchenspezifische Semantik benötigen, etwa detaillierte Maschinenzustände oder Werkzeuginformationen, bleibt OPC UA mit seinen Companion Specifications die robustere Wahl, während reines Sparkplug B eher für einfache Sensor-Telemetrie ohne komplexe Objektstrukturen ausreicht.
Governance: Wer pflegt das Informationsmodell im Unternehmen?
Technisch gut geplante OPC-UA-Architekturen scheitern in der Praxis häufig an fehlender organisatorischer Verantwortung. Sobald mehrere Fachbereiche, etwa Instandhaltung, Produktion und IT, eigene Erweiterungen am Adressraum vornehmen, ohne dies zentral zu koordinieren, entstehen im Zeitverlauf Inkonsistenzen, die die ursprünglich angestrebte Interoperabilität wieder untergraben. Sinnvoll ist deshalb die Benennung einer verantwortlichen Stelle, etwa im Rahmen eines bestehenden Digitalisierungs- oder MES-Teams, die neue Informationsmodell-Erweiterungen prüft, dokumentiert und gegen die verwendeten Companion Specifications abgleicht. Diese Governance-Funktion sollte auch festlegen, unter welchen Bedingungen ein Fachbereich einen neuen unternehmenseigenen Namespace anlegen darf und wie Änderungen an bestehenden Knotenstrukturen freigegeben werden.
Wirtschaftliche Bewertung des Migrationsaufwands
Der Umstellungsaufwand hängt stark vom Digitalisierungsgrad des Bestands ab. Maschinen neuerer Baujahre bringen häufig bereits native OPC-UA-Server mit, sodass sich der Aufwand auf die Informationsmodellierung und Anbindung an MES oder Cloud beschränkt. Ältere Anlagen benötigen zusätzliche Gateway-Hardware oder -Software, deren Kosten in die Wirtschaftlichkeitsrechnung einer Digitalisierungsinitiative einzupreisen sind. In der Praxis amortisiert sich der Migrationsaufwand meist über reduzierte Integrationskosten bei künftigen Systemwechseln, etwa einem MES- oder ERP-Wechsel, da ein einmal etabliertes, standardkonformes Informationsmodell nicht erneut aufwendig angepasst werden muss. Nicht zu unterschätzen ist zudem der Aufbau internen Know-hows: Mitarbeitende aus Instandhaltung und IT sollten mit Adressraummodellierung und Zertifikatsverwaltung vertraut gemacht werden, da externe Dienstleister zwar die Erstintegration übernehmen können, der laufende Betrieb und die Erweiterung um neue Maschinen aber dauerhaft schneller und günstiger gelingen, wenn entsprechendes Wissen im Unternehmen selbst vorhanden ist.
FAQ
Ist OPC UA mit bestehenden OPC-Classic-Installationen kompatibel?
OPC UA ist technisch ein eigenständiger Standard, viele Anbieter stellen jedoch Wrapper-Lösungen bereit, die OPC-Classic-Server über eine OPC-UA-Schnittstelle bereitstellen und so eine schrittweise Migration ermöglichen.
Benötigt jede Maschine einen eigenen OPC-UA-Server?
Nicht zwingend. Für ältere Maschinen ohne native Unterstützung übernimmt ein zentrales Gateway die Übersetzung mehrerer Maschinenprotokolle in einen gemeinsamen OPC-UA-Adressraum.
Welche Rolle spielt PubSub gegenüber dem klassischen Client-Server-Modell?
PubSub eignet sich besonders für die kontinuierliche Übertragung großer Datenmengen an mehrere Abnehmer, etwa Cloud-Plattformen, während das Client-Server-Modell für gezielte Abfragen und Steuerbefehle vorteilhaft bleibt.
Ist eine Companion Specification zwingend erforderlich?
Rechtlich nicht, praktisch aber dringend empfohlen, da ohne standardisiertes Informationsmodell der Interoperabilitätsvorteil von OPC UA weitgehend verloren geht.
Wie aufwendig ist die Zertifikatsverwaltung im laufenden Betrieb?
Mit einer zentralen Public-Key-Infrastruktur und automatisiertem Zertifikatsrollout lässt sich der laufende Aufwand deutlich reduzieren, ein manuelles Zertifikatsmanagement über viele Maschinen hinweg ist hingegen fehleranfällig.
Kann OPC UA auch für Predictive-Maintenance-Anwendungen genutzt werden?
Ja, da OPC UA sowohl historische Daten (HDA-Nachfolgefunktionen) als auch Echtzeitdaten mit Qualitäts- und Zeitstempeln bereitstellt, eignet es sich gut als Datenquelle für Machine-Learning-Modelle in der vorausschauenden Instandhaltung.
Lohnt sich OPC UA auch für kleinere Betriebe mit wenigen Maschinen?
Ja, gerade weil viele moderne Steuerungen bereits native OPC-UA-Server mitbringen, ist der Einstiegsaufwand für einen kleinen Maschinenpark überschaubar, während der Standard bei künftigem Wachstum ohne Systembruch mitskaliert.
Technische Spezifikationen und die vollständige Liste veröffentlichter Companion Specifications stellt die OPC Foundation bereit.
