KommunikationVorteile von OPC UA für die Konstruktion
Von
konstruktionspraxis
18 min Lesedauer
Ob Digitaler Produktpass, Verwaltungsschale oder Manufacturing X: OPC UA stellt die Basis für eine standardisierte, sichere und interoperable herstellerübergreifende Kommunikation. Was bedeutet das für Konstrukteure und wie können sie davon profitieren?
OPC UA ist eine einheitliche Datenschnittstelle für Maschinenmodule und ganze Anlagen. Das bedeutet weniger proprietäre Protokolle und weniger Integrationsaufwand beim Kunden.
(Bild: fotoknips – stock.adobe.com)
OPC UA steht für „Open Platform Communications Unified Architecture“ und ist ein herstellerunabhängiger Kommunikationsstandard, mit dem Maschinen, Geräte und Software in der Industrie sicher und strukturiert Daten austauschen können. Der Standard ist plattformunabhängig, serviceorientiert (SOA) und in der Normenreihe IEC 62541 spezifiziert.[1]
Zentrale Eigenschaften von OPC UA
Als offene, plattformunabhängig Lösung läuft OPC UA von Embedded‑Geräten bis zur Cloud und ist nicht an ein bestimmtes Betriebssystem gebunden. Die Daten werde hierbei nicht nur als „rohe“ Variablen, sondern als Objekte mit klar definierten Eigenschaften, Methoden und Beziehungen beschrieben (objektorientiertes Informationsmodell). Zu den Bestandteilen des OPC-UA-Standards gehören Verschlüsselung, Authentifizierung und Rollenmodelle. Die Sicherheit ist somit integriert und nicht nachträglich „aufgesetzt“. Ferner lässt sich OPC UA einfach skalieren, vom kleinsten Sensor bis hin zur großen verteilten Anlage.[2]
Das lesen sie in diesem Artikel
Zentrale Eigenschaften von OPC UA
Die OPC-UA-Architektur aus Sicht der Konstruktion
Übersicht: Companion Specs für typische Maschinenfunktionen
Nutzen von OPC UA für Konstrukteure
Übersicht: Einordnung klassisches OPC zu OPC UA
Übersicht: Wichtige OPC-UA-Bausteine und ihre Bedeutung für Konstrukteure
Folgen von OPC UA für den konstruktiven Aufbau von Maschinen und Baugruppen mit Übersicht
Typischer Datenweg vom Sensor bis in die Cloud
Übersicht: Relevante Ebenen der Datenwege
OPC UA im Kontext von AAS, DPP und Manufacturing X
Die OPC-UA-Architektur aus Sicht der Konstruktion
Client/Server‑Modell: Ein OPC-UA‑Server auf einer Maschine stellt Daten und Funktionen bereit, wobei OPC-UA‑Clients (z. B. MES/ERP, SCADA/HMI, Edge‑Rechner, Condition Monitoring, Engineering-Tools, Datenlogger) darauf zugreifen.
Pub/Sub‑Ansatz: Der Pub/Sub‑Ansatz von OPC UA ist ein alternatives bzw. ergänzendes Kommunikationsmodell zu Client/Server, bei dem Daten von „Publishern“ als Nachrichten in ein Netzwerk „gestreut“ werden, wobei beliebig viele Empfänger sie abonnieren können. Im klassischen Client/Server‑Modell baut der Client eine Verbindung zum Server auf und fragt Daten gezielt ab. Im Pub/Sub‑Modell werden Daten hingegen in einem „Nachrichten‑Medium“ (Message Oriented Middleware, Broker oder Multicast‑Netzwerk) publiziert; Subscriber holen sich, was sie konfiguriert haben. Hierdurch lassen sich viele Empfänger effizient versorgen, ohne dass der Server für jeden Client einzelne Verbindungen managen muss. Dieser Ansatz dient somit der ereignis‑ oder zyklusbasierten Verteilung von Daten an viele Empfänger (z. B. Motion, TSN‑basierte Kommunikation). Für Konstrukteure bedeutet Pub/Sub, dass Maschinendaten so strukturiert werden sollten, dass sie in semantisch saubere Data Sets passen (etwa „Achszustand“, „Energieprofil“, „Auftragsstatus“)
Informationsmodelle und Companion Specs: Das Kernstück von OPC-UA mit branchen‑ und maschinenspezifischen Modellen, die festlegen, welche Daten wie strukturiert bereitgestellt werden. Besonders hilfreich für Konstrukteure sind OPC-UA-Modelle wie Machinery, Machine Tools, Robotics, PackML, Vision, IO-Link und Devices. OPC UA bedeutet in diesem Zusammenhang nicht nur „Werte lesen“, sondern beschreibt die Struktur und Bedeutung. Der Server stellt hierzu einen Adressraum bereit, der wie ein Objektmodell aufgebaut ist: Objekte (z. B. Maschine, Achse, Ventil, Sensor), Variablen (z. B. Position, Temperatur, Status), Methoden (z. B. Start, Stopp, Referenzfahrt), Events/Alarme (z. B. Störung, Warnung, Grenzwert überschritten) und Beziehungen (z. B. „gehört zu“, „hat Komponente“). Aus Konstruktionssicht kann das wie eine digitale Stückliste plus Funktionsplan betrachtet werden, nur eben maschinenlesbar.[3]
OPC UA ist eine einheitliche Datenschnittstelle für Maschinenmodule und ganze Anlagen. Das bedeutet, weniger proprietäre Protokolle und weniger Integrationsaufwand beim Kunden. Maschinendaten werden hierbei semantisch beschrieben (z. B. Achse, Spindel, Werkzeug statt nur „Tag‑Liste“), wodurch Condition Monitoring, digitale Typenschilder und Services erleichtert werden. Hinzu kommt, und das ist entscheidend, eine bessere Konnektivität an Industrie‑4.0‑ und IoT‑Anwendungen, etwa für OEE‑Auswertungen, Energie‑Monitoring oder vorausschauende Wartung.[5]
Die nachfolgende Übersicht zeigt nochmals die Einordnung eines klassischen OPC zu OPC UA.
Im Standard integriert (Verschlüsselung, Zertifikate)
Einsatzbereich
Steuerungsebene, HMI/SCADA
Vom Feldgerät bis zur Cloud, IIoT / Industrie 4.0
OPC UA ist damit nicht nur ein Protokoll, sondern ein umfassender Rahmen, der festlegt, wie industrielle Informationen strukturiert, sicher übertragen und systemübergreifend verstanden werden kann. Das macht OPC UA zum zentralen Baustein für interoperable Maschinen und datenbasierte Services.
Die wichtigsten OPC UA-Bausteine (vereinfacht) und ihre Bedeutung für Konstrukteure:
Baustein
Bedeutung für Konstrukteure
Address Space Model
Strukturierung von Achsen, Aggregaten, Sensoren in einer logischen Baumstruktur
Information Model
Definition, welche Eigenschaften (z.B. Drehzahl, Temperatur, Wartungszustand) standardisiert sichtbar werden
Security Model
Authentifizierung, Verschlüsselung – Basis für Remote Services und Cloud-Anbindung
Pub/Sub & FX
Basis für echtzeitfähige, Feld-nahe Kommunikation und Motion‑Control‑Szenarien
Die Folgen von OPC UA für den konstruktiven Aufbau von Maschinen und Baugruppen
OPC UA wirkt wie ein Treiber für modulare, datengetriebene Maschinenkonzepte und hat damit unmittelbar Auswirkungen auf Aufbau, Auswahl und Struktur von Baugruppen.
Mehr Modularisierung: OPC UA fördert den modularen Anlagenbau, weil Funktionen als eigenständige Module mit klar definierten digitalen Schnittstellen konzipiert werden. Mechanische Module wie etwa eine Spindel, eine Zuführung oder eine Bearbeitungsstation benötigen in diesem Zusammenhang jeweils ein konsistentes Informationsmodell, das bspw. an „OPC UA for Machinery“ und weitere Companion Specs angelehnt ist. Das Ziel besteht letztendlich in einem „Plug-&-Work“ oder „Plug-&-Produce“, wobei Module mechanisch und elektrisch gekoppelt werden und sich logisch über standardisierte OPC‑UA‑Schnittstellen in einer Linie anmelden.
Informationsmodell als Konstruktionsanforderung: Neben den Anforderungen an Kräften, Genauigkeiten oder Schutzarten kommen weitere Anforderungen an sichtbare Daten hinzu, wie etwa Zustände, Zähler, Diagnose oder Energiedaten. Das Informationsmodell beeinflusst daher z. B. Sensorik‑Positionen, zusätzliche Messstellen, die Zustandsdetektion (z. B. Endschalter versus IO‑Link‑Sensor mit Diagnosedaten) und Wartungspunkte. Das VDMA‑Grundmodell „OPC UA for Machinery“ enthält vor diesem Hintergrund Basisbausteine (Maschinen‑ID, State, Operation State, Effizienz‑ und Wartungsdaten), die für Konstrukteure eine wichtige Orientierungshilfe bieten.
Auswahl OPC UA-fähiger Komponenten: Mit OPC UA als globaler Standard müssen Maschinen in gemischten bzw. verschiedenen Linien herstellerübergreifend interoperabel sein. Hierzu sind klare, unmissverständliche Einordnungen notwendig, denn was ist gemäß Companion Spec als Standard und was als kundenspezifisch zu betrachten? Wie werden Erweiterungen oder Ausbaustufen modelliert, ohne die Interoperabilität zu gefährden? Im konstruktiven Aufbau führt dies letztendlich zu wiederverwendbaren Funktionsmodulen, die sowohl mechanisch als auch digital exakt definiert sind und in verschiedenen Anlagenkonfigurationen eingesetzt werden können.
Auswirkungen auf Engineering‑Prozess und Dokumentation: OPC UA erfordert ein stärkeres interdisziplinäres Engineering: Mechanik, E‑Planung, Software und IT definieren frühzeitig gemeinsam das Informationsmodell als Bestandteil des Lasten‑ bzw. Pflichtenhefts. Digitale Zwillinge und Simulation (z. B. ein modularer Anlagenbau mit virtuellen Inbetriebnahmen) greifen auf dasselbe OPC-UA‑Modell zurück, was wiederum die Struktur und Granularität von Baugruppen im CAD‑System beeinflusst. Die Dokumentation und der Ersatzteilbereich erweitern sich um digitale Typenschilder und maschinenlesbare Beschreibungen von Kapazitäten, Fähigkeiten (Skills) und Services für Service‑Apps und Datenräume.
Kurz gesagt: OPC UA verschiebt den Schwerpunkt von einer „nur mechanisch funktionierenden“ zu einer „mechanisch und digital integrierbaren“ Maschine – und macht das Informationsmodell zur konstruktiven Entwurfsgröße, die sich auf gleicher Ebene wie die Mechanik und die Elektrik bewegt.[6]
Hier nochmals die Zusammenfassung:
Aspekt
Folge für den konstruktiven Aufbau
Typische Fragen für Konstrukteure
Modularisierung & Plug‑&‑Produce
Stärkere Ausrichtung auf funktionale Module mit eigener „digitaler Identität“ und klarer OPC-UA‑Schnittstelle; mechanische, elektrische und digitale Schnittstellen müssen zusammen gedacht werden.
Wie definiere ich Module so, dass sie sich mechanisch, elektrisch und logisch (OPC UA) Plug‑&‑Work in Linien integrieren lassen?
Informationsmodell als Anforderung
Informationsmodell (z.B. OPC UA for Machinery) wird zur zusätzlichen Entwurfsgröße; es bestimmt, welche Zustände, Zähler, Diagnose‑ und Energiedaten sichtbar sein müssen.
Welche Datenpunkte muss meine Baugruppe liefern, damit Service, OEE, Condition Monitoring und DPP sinnvoll funktionieren?
Sensorik, Aktorik & Messstellen
Mehr und „intelligentere“ Sensorik, die nicht nur Schaltsignale, sondern interpretierbare Zustände und Diagnoseinformationen für das OPC-UA‑Modell bereitstellt.
Brauche ich zusätzliche Sensoren oder andere Schnittstellen (IO‑Link, Smart‑Sensoren), um das gewünschte Informationsmodell abzubilden?
OPC UA‑fähige Komponenten
„OPC UA‑ready“ wird Auswahlkriterium bei Antrieben, Steuerungen, Peripherie; Komponenten mit nativer OPC-UA‑Unterstützung reduzieren Gateway‑Aufwand.
Gibt es für diese Funktion bereits Komponenten mit OPC-UA‑Server bzw. Companion‑Spec‑Unterstützung, oder muss ich Gateways vorsehen?
Platzbedarf für Kommunikation
Baugruppen und Schaltschränke müssen Raum für Edge‑Controller, Gateways, Switches, Zertifikat‑Speicher etc. bieten; EMV‑ und Thermikkonzepte sind mit einzuplanen.
Wo platziere ich Kommunikations‑Hardware und wie sichere ich Kühlung, EMV‑Schutz und Servicezugang?
Interoperabilität & Erweiterbarkeit
Saubere Trennung von standardisierten und kundenspezifischen Datenpunkten; Erweiterungen dürfen Interoperabilität nicht stören.
Welche Signale gehören in den standardisierten Teil (Companion Spec) und welche in optionale, kundenspezifische Erweiterungen?
Wiederverwendbare Funktionsmodule
Baugruppen werden als wiederverwendbare „Skills“ mit definierten Fähigkeiten und Daten beschrieben; erleichtert Plattformstrategien und Variantenbildung.
Kann diese Baugruppe so beschrieben werden, dass sie in unterschiedlichen Maschinenplattformen ohne Anpassung wiederverwendbar ist?
Engineering‑Prozess
Frühe, gemeinsame Definition des Informationsmodells durch Mechanik, Elektroplanung, Software und IT; dieses Modell beeinflusst Struktur und Granularität der Baugruppen.
Ist das OPC-UA‑Informationsmodell bereits Teil von Lasten‑/Pflichtenheft und Konstruktionsrichtlinien?
Dokumentation & digitaler Zwilling
Ergänzung klassischer Doku um digitales Typenschild, strukturierte Eigenschaftslisten und OPC-UA‑Knotenstruktur; dieselben Daten werden im digitalen Zwilling verwendet.
Welche Daten aus der Konstruktion (Material, Leistungsdaten, Grenzen) müssen maschinenlesbar im OPC-UA‑Modell und im digitalen Zwilling auftauchen?
Der typische OPC-UA‑Datenweg kann in eindeutig getrennte aber aufeinander aufbauende Ebenen aufgeteilt werden.
Feldebene (Sensor, Aktor, Antrieb): Intelligente Sensoren oder Antriebe erfassen Prozessgrößen (z. B. Position, Temperatur, Energie) und stellen sie über Feldbusse oder teils schon direkt per OPC UA bereit. Konzepte wie „OPC UA vom Sensor bis zur Cloud“ nutzen auf unterer Ebene meist IO‑Link, klassische Feldbusse oder ähnliches setzen weiter oben auf OPC UA‑Informationsmodelle für die Aggregation.
Steuerungsebene (SPS/CNC mit OPC UA‑Server): SPS‑ oder CNC‑Steuerungen bündeln Feldsignale, bilden Maschinenzustände, Zähler sowie Auftragsdaten und stellen diese über einen integrierten OPC-UA‑Server zur Verfügung. OPC UA dient hier als einheitliche Sprache nach „oben“, während nach „unten“ weiterhin unterschiedliche Feldbusse eingesetzt werden können.
Edge‑Ebene (Gateway oder IPC): Ein Edge‑Gateway oder IPC verbindet mehrere Steuerungen, normalisiert Daten und kann sie zusätzlich per MQTT/AMQP in die Cloud hochladen.Solche Geräte agieren als OPC-UA‑Client und ‑Server: Sie lesen Daten aus Steuerungen aus und stellen sie gebündelt für MES, SCADA oder Cloud‑Dienste bereit.
Fabrik‑IT (MES, SCADA, ERP): MES‑ und SCADA‑Systeme greifen über OPC-UA‑Clients auf die Edge‑ oder Steuerungs‑Server zu und verarbeiten Betriebszustände, Alarme, KPIs und Historik. Über standardisierte Informationsmodelle sind Leitstände in der Lage heterogene Maschinenlinien einheitlich zu visualisieren und zu planen.
Cloud‑Ebene (IoT‑Plattform und Analyse): Eine IoT‑Edge‑Komponente übernimmt direkt vor Ort die OPC-UA‑Daten und leitet sie gesichert an Cloud‑Dienste weiter, wo Analyse‑ und Reporting‑Tools darauf zugreifen können.
So entsteht eine durchgängige, standardisierte Datenkette: vom Sensor über Feldbus zur SPS/CNC, von dort über den OPC-UA‑Server zum Edge‑Gateway, weiter zu MES/SCADA und schließlich über eine IoT‑Edge‑Schicht in die Cloud.
Welche Ebenen sind für Konstrukteure relevant?
Ein solcher OPC-UA-Datenweg wird immer dann für Konstrukteure relevant, wenn sich konstruktionsbedingte Entscheidungen unmittelbar auf die Sichtbarkeit, Qualität und Verwendbarkeit von Maschinendaten auswirken.
Daten, die konstruktiv „sichtbar“ gemacht werden müssen: Die Konstruktion entscheidet, welche Zustände und Größen überhaupt erfassbar sind (Sensorpositionen, Messstellen, Zugänglichkeit, etc.). Für Condition Monitoring und Energie‑ sowie Qualitätsdaten sind geeignete Messpunkte an Baugruppen notwendig (z. B. Lager, Spindeln, Führungen, Antriebe), die später im OPC UA‑Modell erscheinen.
Modulstruktur und Informationsmodell einheitlich denken: Die logische Struktur der Maschine im OPC-UA‑Address Space (Module, Stationen, Achsen) sollte zur mechanischen Modulstruktur passen. Beim modularen Aufbau von mechanische Baugruppen sollte zudem gleichzeitig definiert werden, welche Daten dieses Modul als „digitales Objekt“ bereitstellt (z. B. Achsmodul mit Status, Zählern, Diagnose).
Auswahl OPC UA‑fähiger Komponenten und Schnittstellen: Komponenten mit integriertem OPC-UA‑Server oder standardisiertem Informationsmodell reduzieren den Integrationsaufwand und bestimmen die Vernetzungstopologie. Wo indes nur „klassische“ Feldbus‑Geräte eingesetzt werden, müssen Platz, Energieversorgung und Anbindung für Edge‑/Gateway‑Hardware konstruktiv eingeplant werden.
Platzierung von Edge‑ und Kommunikationshardware: Edge‑PCs, Gateways, Switches und ggfs. IoT‑Edge‑Geräte benötigen definierte Einbauorte, Kühlungen, EMV‑Schutz und Servicezugang im Schaltschrank oder direkt an der Maschine. Daher sollten frühzeitig Kabelwege, Anschlusspunkte und Reserven (für zusätzliche Module oder Sensoren) berücksichtigt werden, um damit spätere Cloud‑ oder MES‑Anbindungen nicht zu behindern.
Anforderungen aus MES/Cloud zurück in die Konstruktion: Anforderungen aus MES‑ und Cloud‑Use‑Cases (KPIs, OEE, Energie‑Monitoring, Traceability) müssen konstruktiv abgebildet werden können, da ansonsten später Daten fehlen. Es ist daher für Konstrukteure ratsam früh zu klären, welche Kennzahlen über OPC UA bis in die Cloud gehen sollen und welche zusätzlichen Sensoren oder Zustandsinformationen eine Maschine dafür benötigt.[8]
Die wichtigsten Aspekte nochmals zusammengefasst:
Aspekt
Relevanz für Konstrukteure
Konkrete Fragestellungen in der Konstruktion
Messstellen & Sensorik
Nur was konstruktiv messbar ist, kann später über OPC UA in MES/Cloud sichtbar werden.
Wo platziere ich Sensoren und Messstellen, damit Zustände von Lagern, Spindeln, Führungen, Antrieben, Energieflüssen erfassbar sind?
Wo plane ich Platz, Montagepunkte und Reserveleistung für Edge‑PCs, Gateways, Switches und zukünftige Erweiterungen ein?
Verkabelung & Netzwerktopologie
Daten‑ und Versorgungsleitungen müssen für spätere Vernetzung ausgelegt sein.
Sind Netzwerkkabelwege, Switch‑Standorte und Reserven so angelegt, dass zusätzliche Module/Sensoren später einfach integrierbar sind?
Anforderungen aus MES/Cloud
KPIs und Analysen definieren, welche Daten konstruktiv bereitgestellt werden müssen.
Welche Kennzahlen (OEE, Energie, Qualität, Durchsatz) sollen oben ankommen – und welche Signale/Sensoren braucht meine Konstruktion dafür?
Wartung & Zugänglichkeit
Für Austausch, Nachrüstung und Diagnose müssen Komponenten gut zugänglich sein.
Sind Sensoren, Edge‑Geräte und Kommunikationskomponenten so angeordnet, dass Service und Retrofit (weitere OPC-UA‑Signale) problemlos möglich sind?
OPC UA im Kontext von AAS, DPP und Manufacturing X
Wie bereits erwähnt, ist OPC UA der „Datenmotor“ für Anwendungen wie Verwaltungsschale (AAS), Digitaler Produktpass (DPP) und Manufacturing X.
Die Verwaltungsschale (AAS) ist der standardisierte digitale Zwilling eines Assets – also die „Lebenszyklusakte“ einer Maschine oder Komponente. AAS‑Server können explizit ein OPC-UA‑API anbieten. AAS‑Teilmodelle lassen sich als OPC-UA‑Nodesets serialisieren und über einen OPC-UA‑Server zugänglich machen. Umgekehrt kann eine AAS auf die Daten des OPC-UA‑Servers eines Assets zugreifen und diese in ihre Teilmodelle integrieren (z. B. Betriebsdaten, Zustände, Identifikation).
OPC UA transportiert somit die „Roh‑ und Zustandsdaten“ der Maschine, die AAS „verpackt“ sie lebenszyklusorientiert in Teilmodelle (z. B. Nameplate, Maintenance, Condition) und stellt sie standardisiert anderen Systemen bereit.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel Communications Group GmbH & Co. KG, Max-Planckstr. 7-9, 97082 Würzburg einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von redaktionellen Newslettern nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung, Abschnitt Redaktionelle Newsletter.
Der Digitale Produktpass benötigt vertrauenswürdige, maschinenlesbare Daten zu Material, CO₂‑Fußabdruck, Nutzung, Wartung und Recycling entlang der gesamten Wertschöpfungskette. OPC UA liefert dafür standardisierte Produktions‑ und Zustandsdaten aus Maschinen, z. B. Energieverbräuche, Qualitätskennzahlen oder Betriebsstunden, auf Basis von Companion Specs.
Über AAS‑Teilmodelle und Brancheninitiativen wie Catena‑X lassen sich diese OPC-UA‑basierten Produktionsdaten in DPP‑Strukturen überführen und in branchenspezifische Datenräumen verteilen.
Wer OPC-UA‑fähige Maschinen baut, liefert die technische Basis für die spätere automatisierte oder halb-automatisierte Übertragung von Produktionsdaten in Digitale Produktpässe, anstelle sie manuell zusammenstellen zu müssen.
Manufacturing X beschreibt industrielle Datenräume, in denen Unternehmen Produktions‑ und Produktdaten souverän, sicher und standardisiert austauschen. ZVEI und VDMA nennen OPC UA ausdrücklich als zentrales Fundament für die standardisierte Erfassung und Modellierung von Produktionsdaten, die dann über Connectoren in Datenräume eingespeist werden. Initiativen wie umati zeigen, wie heterogene OPC UA‑Daten aus Maschinen zu einem gemeinsamen Produktionsdatenraum zusammengeführt werden können – ein wesentlicher Baustein für Manufacturing X. OPC UA sorgt daher für eine interoperable, semantisch einheitliche Datenbasis auf Maschinenebene, auf die dann Manufacturing X‑Konnektoren und Datenraum‑Technologien aufsetzen.
Fazit: Konstrukteure definieren mit, welche Eigenschaften und Zustände einer Maschine im OPC-UA‑Informationsmodell erscheinen – diese gehen später in AAS‑Teilmodellen, Datenräumen und DPPs. Bauteile und Module sollten daher idealerweise so beschrieben werden, dass sich aus ihren OPC-UA‑Daten konsistente AAS‑Teilmodelle (z. B. Nameplate, Technical Data, Condition, Energy) ableiten lassen. Wer OPC UA, AAS und Datenraum‑Anforderungen (Manufacturing X, Catena‑X) als einheitliche Basis betrachtet, konstruiert Maschinen von Anfang an „DPP‑fähig“ und anschlussfähig an zukünftige Ökosysteme.[9]