Tiefenanalyse des OPC UA-Protokolls: Hintergrund, Entwicklung, Prinzipien bis zur Konfigurationspraxis
Aktualisiert: 12. Okt.
Einleitung: Warum OPC UA zur "Standardsprache" des industriellen Vernetzungszeitalters wurde
Industrie 4.0 und das industrielle Internet der Dinge verbinden Automatisierungssysteme, die Daten zuvor über getrennte Herstellerschnittstellen austauschten. Bei der Integration geht es um mehr als die Übertragung von Bytes: Anwendungen müssen sich über die Bedeutung der Daten, das Aktualisierungsverhalten und die Sicherheit verständigen. OPC UA (Open Platform Communications Unified Architecture) unterstützt dies mit einer plattformunabhängigen Architektur, einem Informationsmodell, Diensten und definierten Kommunikations-Mappings. Modbus, PROFIBUS und andere etablierte Protokolle bleiben für ihre vorgesehenen Aufgaben nützlich; möglicherweise ist ein Gateway erforderlich, um Gerätedaten einem OPC-UA-Modell zuzuordnen.
OPC UA verbindet interoperable Informationsmodelle, Anwendungssicherheitsmechanismen und Implementierungen von eingebetteten Geräten bis hin zu Unternehmenssystemen. Begleitspezifikationen können Geräten verschiedener Hersteller ein gemeinsames Vokabular geben. Zertifikate, SecurityPolicies, Benutzerberechtigungen und das operative Vertrauensmanagement müssen dennoch korrekt konfiguriert werden. Eine Fertigungslinie kann Messwerte von SPSen über ein dokumentiertes Modell für Leit- und Wartungsanwendungen bereitstellen; der tatsächliche Nutzen hängt von den Geräten, Zuordnungen und der Bereitstellung ab. Kompatibilität, Angaben zum installierten Bestand, Marktprognosen und Leistungswerte einer namentlich genannten Fabrik lassen sich nicht aus der Architektur ableiten.
Kurz gesagt, OPC UA ist nicht nur ein technisches Protokoll, sondern die "universelle Grammatik" der industriellen Digitalisierung, die Maschinen ermöglicht, so effizient und sicher wie Menschen zu "kommunizieren" und den Übergang von "Automatisierung" zu "Intelligenz" voranzutreiben.
Ein Industrierouter kann Datenverkehr zwischen einem SPS-Netz und einer Leitanwendung übertragen, ohne die Werte in einer OPC-UA-Nachricht zu verstehen. Ein Gateway oder eine SPS kann den OPC-UA-Server bereitstellen, während ein Client an anderer Stelle Daten liest oder abonniert. Vor der Aussage „der Router unterstützt OPC UA“ müssen diese Rollen klar sein. Pakete weiterleiten, einen Endpunkt anbieten und ein anderes Protokoll in OPC UA übersetzen sind verschiedene Funktionen.
Hintergrund und Entwicklungsgeschichte von OPC UA
Die Entstehung von OPC Classic
OPC Classic entstand, um den Bedarf an separaten Windows-Treibern und Schnittstellen für jeden Automatisierungshersteller zu verringern. Die Technologie Microsoft COM/DCOM standardisierte die Kommunikation zwischen industriellen Anwendungen. Die wichtigsten Classic-Spezifikationen betrafen aktuelle Daten, historische Daten und Alarme/Ereignisse:
DA (Data Access): Echtzeit-Lesen und -Schreiben von Variablen, unterstützt Abonnementmechanismen.
HDA (Historical Data Access): Historische Datenabfrage und -aggregation.
AE (Alarms & Events): Ereignis- und Alarmbenachrichtigungen.
OPC Classic etablierte sich in SCADA- und DCS-Installationen. Die Abhängigkeit von COM/DCOM erschwerte die Bereitstellung über verschiedene Betriebssysteme und Netzwerkgrenzen hinweg. DCOM verfügt über eigene Authentifizierungs- und Zugriffskontrollen; OPC Classic sollte daher nicht so beschrieben werden, als biete es überhaupt keine Autorisierung oder Verschlüsselung. OPC UA wurde entwickelt, um diese Windows-Abhängigkeit zu beseitigen und einen gemeinsamen Adressraum, Dienste und ein Kommunikationssicherheitsmodell für ein breiteres Spektrum von Systemen bereitzustellen.
Tabellenvergleich: OPC Classic vs. Moderne Anforderungen
Aspekt | Kontext von OPC Classic | Einschränkung von OPC Classic | Unterschied bei OPC UA |
|---|---|---|---|
Plattform | COM/DCOM-Schnittstellen wurden für Windows-Umgebungen entwickelt. | Plattformübergreifende Bereitstellungen können zusätzliche Integrationsarbeit erfordern. | Die Spezifikation ist auf plattformunabhängige Implementierungen ausgelegt; unterstützte Profile unterscheiden sich je nach Produkt. |
Datenzugriff | DA, HDA und AE behandeln Variablenzugriff, Historie und Alarme/Ereignisse. | Die Classic-Spezifikationen verwenden nicht das OPC-UA-Informationsmodell des AddressSpace. | UA-Dienste und Informationsmodelle unterstützen strukturierte Daten und Beziehungen; Begleitmodelle sind anwendungsspezifisch. |
Sicherheit | Die Sicherheit hängt von der jeweiligen COM/DCOM-, Betriebssystem- und Standortkonfiguration ab. | Das Sicherheitsverhalten hängt von Bereitstellung und Konfiguration ab. | UA definiert Anwendungs- und Kommunikationssicherheitsmechanismen; Endpunkte und Benutzer müssen diese konfigurieren und überprüfen. |
Erweiterbarkeit | Classic-Schnittstellen unterstützen ihre festgelegten Anwendungsfälle für den Datenzugriff. | Für die Verbindung mit anderen Anwendungen können Gateways oder Zuordnungen erforderlich sein. | UA unterstützt erweiterbare Informationsmodelle sowie Client/Server- oder PubSub-Muster, sofern diese implementiert sind. |
Von OPC Classic zu einer plattformübergreifenden Architektur
OPC Classic nutzte Microsoft COM/DCOM für den Datenzugriff unter Windows. OPC UA ist in der Normenreihe IEC 62541 beschrieben und definiert Adressraum, Dienste und Kommunikationsabbildungen ohne diese Windows-Abhängigkeit. Eine Umstellung erfordert mehr als einen offenen Port: Bestimmen Sie, welche SPS, welches Gateway oder welcher Server Daten anbietet, welcher Client sie nutzt und wie ältere Tags mit ihrer Bedeutung im neuen Adressraum abgebildet werden. Ein Router transportiert die Verbindung, erstellt diese Zuordnung aber nicht allein durch Routing.
Die Einführung und Vision von OPC UA
Die OPC Foundation entwickelte OPC UA als Nachfolger der Classic-Spezifikationen. Ziel war eine einheitliche Architektur, die industrielle Informationen abbilden und Dienste unabhängig von Windows COM/DCOM bereitstellen kann. Die Vision bestand darin, die standardisierte Kommunikation auf Geräte, Betriebssysteme und Unternehmensanwendungen auszuweiten:
Plattformunabhängigkeit: Adressraum und Dienste unabhängig von einem bestimmten Betriebssystem, einer Implementierungssprache oder einer COM/DCOM-Laufzeitumgebung definieren.
Semantischer Austausch: Werte mit Typen, Attributen und Beziehungen beschreiben, damit Verbraucher ihre Bedeutung einordnen können.
Einheitliche Dienste: Erkennung, aktuelle und historische Daten, Methoden, Ereignisse und Subscriptions unterstützen, sofern der Server die entsprechenden Funktionen implementiert.
Dieser Ansatz unterstützt die Integration zwischen Steuerungssystemen und Anwendungen wie MES, Instandhaltung und Unternehmensinformationssystemen. Auch bei der Einführung von UA sind ein definiertes Informationsmodell, kompatible Anwendungsfunktionen und geprüfte Zuordnungen vorhandener Tags erforderlich. Die Wahl eines Protokolls allein belegt keine bestimmte Verkürzung der Integrationszeit.
Internationale Standardisierung und Ökosystementwicklung
OPC UA ist in der Normenreihe IEC 62541 standardisiert. Die Spezifikationen behandeln Architektur, Sicherheit, Adressraum, Dienste, Informationsmodell, Mappings und weitere Funktionen. Zum Ökosystem der OPC Foundation gehören Automatisierungsanbieter, Softwareentwickler, Anwender und Organisationen, die Domänenmodelle definieren. Verwenden Sie für ein Projekt die aktuell veröffentlichte Version der jeweils relevanten Spezifikation, statt anzunehmen, eine historische Anzahl von Teilen oder Mitgliedern beschreibe das gesamte Ökosystem.
Begleitspezifikationen: Branchengruppen definieren gemeinsame Modelle für Anlagen und Anwendungen, etwa für Maschinen und automatische Identifikation. Prüfen Sie das genaue Modell und die Version, die beide Anwendungen unterstützen.
Bereitstellung: Fabriken, Versorger und andere Branchen nutzen OPC UA zur Datenintegration; eine landesweite Zahl installierter Systeme lässt sich nicht aus dem Standard ableiten.
Open-Source-Implementierungen: Projekte wie open62541 stellen Entwicklern eine UA-Implementierung zur Verfügung. Plattformunterstützung, Funktionen und Konformität hängen von der gewählten Version und dem Build ab.
Interoperabilität setzt eine Übereinstimmung bei Profilen, Diensten, Informationsmodellen und Sicherheitseinstellungen voraus. Konformitätstests und eine Zertifizierung durch die OPC Foundation können Nachweise für einen klar definierten Produktumfang liefern. Sie ersetzen jedoch nicht den gemeinsamen Test des konkreten Clients, Servers und der Anwendungsanforderungen.
Tabelle: Wichtige Meilensteine
Meilenstein | Was die bereitgestellten Spezifikationsquellen belegen | Bedeutung für die Entwicklung |
|---|---|---|
OPC Classic | Die Windows-basierten COM/DCOM-Spezifikationen umfassen DA, HDA und AE. | Für Altsysteme kann ein ausdrücklich konfiguriertes Gateway oder eine Datenzuordnung erforderlich sein. |
OPC UA | Eine einheitliche Architektur definiert Dienste, Informationsmodelle, Kodierungen und Mappings. | Plattformunterstützung macht die Prüfung der Profile und Gerätemodelle nicht überflüssig. |
IEC 62541 | OPC UA wird als mehrteilige IEC-Spezifikationsreihe veröffentlicht. | Verwenden Sie für die implementierte Funktion den jeweils relevanten Teil und die passende Version. |
Version 1.04 | Die offizielle Versionshistorie von Teil 1 nennt den 22.11.2017 als Veröffentlichungsdatum von Version 1.04. | Die Funktionsunterstützung muss anhand der relevanten Spezifikationsversion und des Produktprofils geprüft werden. |
Version 1.05.06 | Die bereitgestellte Historie von Teil 1 nennt den 22.10.2025 als Veröffentlichungsdatum von Version 1.05.06. | Dies ist die in der bereitgestellten Quellenaufnahme erfasste Version und keine Garantie, dass jedes Produkt sie implementiert. |
PubSub, TSN und KI-bezogene Modelle | Die bereitgestellte PubSub-Spezifikation definiert PubSub-Modelle und Mappings. Die Quellen belegen keine allgemeine Produktunterstützung, Leistung oder ein Veröffentlichungsdatum für jedes Integrationsthema. | Betrachten Sie diese als Funktionen oder Themen, die anhand der gewählten Spezifikation und Implementierung bewertet werden müssen. |
Gesamtarchitektur von OPC UA
Zukunftsorientierte plattformübergreifende Architektur
OPC UA verwendet eine serviceorientierte Architektur (SOA), deren Kern die Abstraktionsschicht ist und die Unabhängigkeit von Betriebssystem/Hardware sicherstellt. Wichtige Komponenten:
Anwendung und Informationsmodell: Geschäftslogik, Knoten, Werte und das Dienstverhalten implementieren, das anderen Anwendungen bereitgestellt wird.
Implementierung oder SDK: stellt APIs und Plattformintegration bereit; .NET, Java, C/C++ und andere Sprachen sind Implementierungsoptionen und keine vorgeschriebenen Protokollschichten.
Kommunikations-Mappings: Kodierungen, Sicherheit und Transportprofile auswählen, die von den kommunizierenden Anwendungen tatsächlich unterstützt werden.
UA-Implementierungen können auf eingebetteten Steuerungen, Edge-Computern sowie Unternehmens- oder Cloud-Systemen laufen, sofern die erforderlichen Ressourcen und Profile verfügbar sind. Plattformübergreifende Unterstützung schafft für sich genommen keine Zero-Trust-Bereitstellung. Im Vergleich zu einer allgemeinen HTTP-API definiert UA einen industriellen Adressraum, Dienste und Konventionen für Informationsmodelle; die Implementierung muss Identitäten, Sitzungen und Zugriffsberechtigungen weiterhin verwalten.
OPC UA definiert ein Informationsmodell und Dienste zum Auffinden, Lesen, Schreiben und Abonnieren von Daten. Der Überblick der OPC Foundation trennt die Architektur vom einzelnen Netzwerkgerät. In einem üblichen Client/Server-Aufbau bietet der Server einen Endpunkt an und der Client baut eine Sitzung auf. Es gibt weitere Kommunikationsmuster; prüfen Sie deshalb das tatsächliche Anwendungsprofil, statt für jeden Einsatz denselben Pfad anzunehmen.
Zeichnen Sie den Weg vom Client zum Server mit Adresse und Port, DNS- oder VPN-Endpunkt, Routerschnittstellen, Firewall, NAT und möglichem Gateway. Befindet sich ein Modbus-Gerät hinter dem Gateway, muss dieses Register samt Bedeutung in ein OPC-UA-Modell abbilden. Die IP-Weiterleitung des Routers erledigt diese Umsetzung nicht. Der Modbus-Leitfaden erläutert die getrennten Register- und Transportfragen.
Komponente | Zu prüfende Rolle | Nachweis |
|---|---|---|
SPS oder Gateway | Serverendpunkt, Namespace, NodeIds und Aktualisierung | Client kann vorgesehene Werte finden und lesen |
Industrierouter | IP-Pfad, Segmentierung, NAT/VPN und erlaubte Richtung | Berechtigter Client erreicht nur den vorgesehenen Endpunkt |
OPC-UA-Client | Vertrauenseinstellungen, Sitzung und Abonnements | Lesen, Schreiben oder Alarme erfüllen die Anwendungsvorgabe |
Betriebsteam | Zertifikate, Protokolle, Sicherungen und Verantwortlichkeit | Vertrauen und Dienst kehren nach geplanter Störung zurück |
IP-Routing kann OPC-UA-Datenverkehr übertragen. Es stellt jedoch nicht automatisch einen OPC-UA-Server bereit und wandelt auch kein anderes Protokoll um.
Kommunikationsstapelstruktur
OPC UA lässt sich anhand von Anwendungen und Informationsmodellen, Diensten, Datencodierungen, Sicherheitsmechanismen und Transport-Mappings verstehen. Diese bilden keinen vorgeschriebenen siebenschichtigen OSI-Stack. Das UA-Anwendungsmodell ist von den darunterliegenden Netzwerk- und physischen Verbindungen zu unterscheiden:
Anwendung und Dienste: industrielle Informationen modellieren und Vorgänge wie Browse, Read, Write, Call und die Verwaltung von Subscriptions ausführen.
Datendarstellung: die für das gewählte Mapping und Profil definierten Kodierungen verwenden; UA Binary, XML und JSON erfüllen unterschiedliche spezifizierte Zwecke.
Kommunikations-Mapping: einen unterstützten Client/Server- oder PubSub-Transport samt Nachrichten- und Sicherheitsregeln auswählen.
Zugrunde liegendes Netzwerk: TCP/IP, UDP/IP, Ethernet sowie physische oder drahtlose Medien stellen entsprechend dem gewählten Mapping die Verbindung bereit. Sie sind keine zusätzlichen UA-Dienstschichten.
Sicherheit: Anwendungsidentität, SecureChannel- oder Nachrichtenschutz und Benutzerautorisierung müssen im Zusammenhang mit dem gewählten Kommunikationsmuster berücksichtigt werden.
Latenz und Echtzeitverhalten hängen von Anwendungen, Kodierung, Transport, Netzwerkauslegung, Gerätelast und Konfiguration ab. TSN oder ein bestimmtes Transportprofil kann Teil eines entworfenen Systems sein, doch die Wahl von OPC UA garantiert keine feste Ende-zu-Ende-Latenz.
Tabelle: Detaillierte Kommunikationsstapel-Ebenen
Aspekt | OPC-UA-Konzept | Beispiel | Prüfung |
|---|---|---|---|
Anwendung | Client/Server-Dienste oder Informationsaustausch über PubSub. | Browse- und Read-Dienste; DataSet-Nachrichten eines Publishers. | Bestätigen Sie, dass das Server- oder PubSub-Profil das erforderliche Verhalten unterstützt. |
Informationsmodell | Nodes, Attributes und References beschreiben Daten und Beziehungen. | Eine Variable stellt einen Wert mit einem DataType und weiteren Attributes dar. | Verwenden Sie das Gerätemodell und die Namespace-URI; leiten Sie die Bedeutung nicht allein aus einem Namen ab. |
Kodierung | Das gewählte Mapping legt fest, wie Nachrichten kodiert werden. | UA Binary oder JSON in den jeweils anwendbaren Mappings. | Prüfen Sie Mapping und Endpunkt; setzen Sie nicht voraus, dass jede Kodierung unterstützt wird. |
Transport | Mappings übertragen OPC-UA-Nachrichten über unterstützte Transporte. | OPC UA TCP für Client/Server; spezifizierte UDP-, Ethernet- oder Broker-Mappings für PubSub. | Prüfen Sie den angekündigten Endpunkt oder das PubSub-Profil sowie die Produktunterstützung. |
Sicherheit | MessageSecurityMode, SecurityPolicy, Benutzeridentität, Zertifikate und Netzwerkkontrollen erfüllen unterschiedliche Aufgaben. | Nachrichtenschutz über den SecureChannel oder ein unterstütztes TLS-Mapping. | Konfigurieren Sie jede erforderliche Ebene; keine einzelne davon belegt Ende-zu-Ende-Schutz. |
Informationsmodell und Datenorganisation
Das Informationsmodell nutzt Nodes, Typen, Attributes und References, um industrielle Informationen zu beschreiben. XML-NodeSet-Dateien können Modelldefinitionen austauschen; XML ist nicht die einzige Repräsentation für Laufzeitdaten. Zu den zentralen Modellierungskonzepten gehören:
Object: stellt eine Entität dar oder gruppiert Informationen, zum Beispiel zu einem Gerät.
Variable: stellt einen typisierten Value mit zugehörigen Attributes wie DataType und ValueRank bereit.
Method: stellt einen aufrufbaren Vorgang mit definierten Ein- und Ausgabeparametern bereit.
Reference: verknüpft Nodes über einen ReferenceType; Beziehungen können hierarchisch oder nicht hierarchisch sein.
Der AddressSpace ist ein Graph aus Nodes und typisierten References. Ein Client durchsucht häufig eine hierarchische Ansicht dieses Graphen; Nodes können jedoch an mehreren Beziehungen beteiligt sein. BrowseName, DisplayName, Description, Typen und References helfen einem Verbraucher, Informationen zu finden und einzuordnen; eine angezeigte Bezeichnung allein ist keine stabile NodeId.
Kerntechnologische Eigenschaften von OPC UA
Sicherheitssystem (Authentifizierung, Verschlüsselung, Autorisierung)
OPC UA definiert ein eigenes Anwendungssicherheitsmodell und eigene Kommunikations-Mappings. Für eine Client/Server-Bereitstellung sind Anwendungsauthentifizierung, Nachrichtenschutz und Benutzerautorisierung getrennt zu bewerten:
Anwendungsauthentifizierung: Prüfen Sie das Zertifikat und die Identität der Peer-Anwendung sowie Vertrauenskette, Gültigkeit und die relevanten Zertifikatsprüfungen für den gewählten Endpunkt.
Nachrichtenschutz: Wählen Sie eine kompatible SecurityPolicy und einen passenden MessageSecurityMode. Algorithmen und Schlüssellängen werden durch diese Policy festgelegt, nicht durch eine universelle AES/SHA-Kombination.
Benutzerauthentifizierung und Autorisierung: Wählen Sie ein unterstütztes Benutzer-Token und erteilen Sie dem Konto nur die erforderlichen Berechtigungen für Nodes und Dienste. Das Vertrauen in das Anwendungszertifikat ist eine separate Entscheidung.
Betrieb: Verwalten Sie Vertrauenslisten, Zertifikatserneuerung, Sperrinformationen, Protokolle und Audit-Verhalten entsprechend den Produktfunktionen.
MessageSecurityMode legt None, Sign oder SignAndEncrypt fest. SecurityPolicy spezifiziert die Sicherheitsalgorithmen und zugehörigen Regeln; Basic256Sha256 ist der Name einer Policy und kein vierter Nachrichtenmodus. Wählen Sie eine gegenseitig unterstützte Policy und einen geeigneten Modus für die Bereitstellung. OPC-UA-Sicherheitsoptionen begründen nicht automatisch die Konformität mit IEC 62443. Die MQTT-Sicherheit hängt ebenfalls von Bereitstellung, Transportschutz und Anwendungsautorisierung ab; allein der Protokollname ist keine Sicherheitsbewertung.
Tabelle: Vergleich der Sicherheitsmodi
Einstellung | Steuert | Schutz/Wirkung | Prüfung |
|---|---|---|---|
MessageSecurityMode: None | Keine Nachrichtensignatur und -verschlüsselung über den SecureChannel. | Bietet auf Nachrichtenebene weder Vertraulichkeit noch Integrität. | Nur verwenden, wenn die Bereitstellung und die Endpunkt-Policy dies zulassen. |
MessageSecurityMode: Sign | Signiert Nachrichten. | Bietet Nachrichtenintegrität und Authentifizierung, verschlüsselt aber keine Nachrichteninhalte. | Zertifikate, SecurityPolicy und Endpunktunterstützung überprüfen. |
MessageSecurityMode: SignAndEncrypt | Signiert und verschlüsselt Nachrichten. | Bietet Nachrichtenintegrität und Vertraulichkeit über den unterstützten SecureChannel. | Unterstützung beider Endpunkte, Zertifikatsvertrauen und gewählte Policy überprüfen. |
SecurityPolicy, z. B. Basic256Sha256 | Legt Sicherheitsalgorithmen und zugehörige Anforderungen fest; ist kein MessageSecurityMode. | Zulässige Kombinationen und aktuelle Empfehlungen hängen von Spezifikations- und Profilversion ab. | Anhand der Endpunktunterstützung und aktueller Sicherheitsempfehlungen wählen; Einstellungen nicht allein aufgrund ihrer Bezeichnung kombinieren. |
Eine funktionierende TCP-Verbindung ist noch keine vertrauenswürdige OPC-UA-Sitzung.
Prüfen Sie Serverendpunkt, unterstützte Sicherheitsrichtlinien, Anwendungszertifikate, Vertrauenslisten und Nutzerauthentifizierung anhand der aktuellen Produktdokumentation. Das OPC-UA-Sicherheitsmodell beschreibt diese Begriffe, zertifiziert aber keinen Router oder Gateway. Planen Sie Erneuerung und Widerruf von Zertifikaten vor dem unbeaufsichtigten Betrieb eines Fernstandorts.
SecurityPolicy, MessageSecurityMode, Vertrauen in das Anwendungszertifikat und Benutzerberechtigungen sind getrennte Einstellungen. Prüfen Sie alle vier.
Dienst (Services)-Mechanismus
OPC UA fasst verwandte Vorgänge in Service Sets zusammen. Clients verwenden unterstützte Dienste für Erkennung, Sitzungen, Datenzugriff, Methoden und Subscriptions. Die verfügbaren Funktionen hängen vom Serverprofil und der Konfiguration ab:
Erkennung: Server finden und ihre Endpunktbeschreibungen sowie unterstützten Sicherheitsoptionen abfragen.
SecureChannel und Session: bei entsprechender Konfiguration eine geschützte Anwendungskommunikation einrichten, eine Session erstellen und mit einer zugelassenen Benutzeridentität aktivieren.
Read und Write: auf Node-Attribute wie den Value einer Variable zugreifen, sofern der Server dies erlaubt; für den Zugriff auf historische Daten dienen HistoryRead und HistoryUpdate statt des gewöhnlichen Read/Write.
Subscriptions und MonitoredItems: Datenänderungen oder Ereignisse mit Sampling-, Warteschlangen- und Veröffentlichungsverhalten überwachen; eine Subscription ist nicht auf Ereignisse beschränkt.
Call: eine bereitgestellte Method mit den erforderlichen Argumenten und Berechtigungen aufrufen.
Dienste verwenden das Anfrage-Antwort-Modell, Fehlercodes sind standardisiert (z.B. BadNodeIdUnknown).
Informationsmodellierung
OO-Modellierung unterstützt Vererbung/Komposition:
Typdefinitionen: ObjectType- und VariableType-Nodes definieren Typen für Objects und Variables; DataType-Nodes definieren Wertetypen. Diese NodeClasses sind nicht selbst die Namen konkreter Basistypen.
Instanzen: Objects und Variables instanziieren die jeweils relevanten Modelltypen; Methods stellen Vorgänge mit definierten Argumenten und Berechtigungen dar.
Erweiterungen: Anwendungs-Namespaces registrieren und anwendbare Begleitspezifikationen verwenden, etwa Modelle für automatische Identifikation, die beide Anwendungen in einer kompatiblen Version unterstützen.
Informationsmodelle machen Struktur und Bedeutung von Daten explizit. Verbraucher können unterstützte Begleitmodelle und Metadaten zur Interpretation heranziehen. Dies kann Analyse- oder KI-Anwendungen helfen; das Vorhandensein von UA-Daten garantiert jedoch nicht, dass ein Verbraucher ein unbekanntes Modell versteht.
Tabelle: Modellierungselementtypen
Elementtyp | Beschreibung | Attributes / zugehörige Eigenschaften | Beispiel für Zugriff/Beziehung |
|---|---|---|---|
Object | Stellt eine Entität oder Gruppierung dar. | BrowseName, DisplayName, EventNotifier | Seine Attributes durchsuchen und lesen; es kann References wie component oder organization besitzen. |
Variable | Stellt einen Wert dar. | Value, DataType, ValueRank, AccessLevel | Read; Write nur, wenn beschreibbar und autorisiert; Überwachung über ein MonitoredItem, sofern unterstützt. |
Method | Stellt einen aufrufbaren Vorgang dar. | Executable, UserExecutable; InputArguments und OutputArguments sind Properties | Die Method aufrufen, wenn sie vorhanden und zulässig ist. |
ReferenceType | Definiert, wie Nodes miteinander verknüpft sind. | IsAbstract, Symmetric, InverseName | Beispiele sind Organizes, HasComponent und HasSubtype. |
DataType | Definiert den Typ eines Variable-Werts. | IsAbstract, DataTypeDefinition, sofern definiert | Den relevanten Node lesen oder durchsuchen; GetEndpoints wird dafür nicht verwendet. |
View | Definiert eine Teilmenge oder Projektion des AddressSpace. | View-spezifische Attributes | Innerhalb der View browsen, sofern der Server dies unterstützt. |
Datenübertragungsmodi (Client/Server, Pub/Sub)
Client/Server: Ein Client nutzt Dienste, um mit einem Server Nodes zu durchsuchen, zu lesen, zu schreiben, Methoden aufzurufen oder Subscriptions einzurichten. Konfiguration und kontinuierliche Überwachung werden unterstützt, sofern die entsprechenden Funktionen implementiert sind.
PubSub: Publisher erzeugen DataSet-Nachrichten für Subscriber über einen unterstützten Transport und ein passendes Nachrichten-Mapping. Metadaten für Reader und Writer, Identifikatoren, Zustellverhalten und Sicherheit müssen separat konfiguriert werden. PubSub ist in Teil 14 spezifiziert und belegt keine RTPS/DDS-Kompatibilität.
PubSub kann ausgewählte DataSets an mehrere Verbraucher verteilen, ohne dass jeder Verbraucher denselben Client/Server-Subscription-Pfad einrichten muss. Subscriptions über Client/Server vermeiden ebenfalls wiederholtes Polling auf Anwendungsebene für jeden einzelnen Wert. Vergleichen Sie Fan-out, Aktualisierungsanforderungen, Metadaten, Wiederherstellung und Sicherheit für die konkrete Bereitstellung, statt anzunehmen, PubSub benötige immer weniger Bandbreite.
Tabelle: Vergleich der Übertragungsmodi
Modus | Kommunikationsmuster | Mögliche Funktionen | Auswahl/Prüfung |
|---|---|---|---|
Client/Server | Ein Client ruft Dienste auf einem Server auf. | Erkennung, Browsing, bedarfsabhängiger Zugriff, Methoden, Subscriptions und weitere unterstützte Dienste. | Endpunktprofil, Servergrenzen, Benutzerberechtigungen und gemessene Last prüfen. |
PubSub | Publisher senden konfigurierte DataSet-Nachrichten an passende Subscriber. | Eins-zu-viele-Verteilung über einen unterstützten PubSub-Transport und ein entsprechendes Mapping. | Metadaten, Aktualisierungsplan, Transport, Zuordnung der Reader, Sicherheit und Netzwerkverhalten prüfen. |
Client/Server oder PubSub nach Aufgabe wählen
Im üblichen Client/Server-Muster entdeckt ein Client einen Endpunkt, baut sicheren Kanal und Sitzung auf und durchsucht, liest oder abonniert überwachte Elemente. OPC UA PubSub ist ein eigenes Veröffentlichungsmuster mit eigener Transport-, Sicherheits- und Teilnehmerkonfiguration. Nicht jeder Client/Server-Endpunkt wird dadurch zum Broker oder Multicast-Sender. Dokumentieren Sie die tatsächlich unterstützten Muster von Server und Client, bevor Sie Routen, Firewall und WAN-Wiederherstellung planen. Für einen zentralen SCADA-Client mit wenigen bekannten Knoten ist der dokumentierte Client/Server-Pfad ein sinnvoller Ausgangspunkt.
Adressraum und Knotenmodell von OPC UA
Der AddressSpace ist ein Graph mit dem standardisierten RootFolder (ns=0;i=84). Zu seinen Standard-Unterknoten gehören ObjectsFolder (ns=0;i=85), TypesFolder und ViewsFolder. Eine NodeId besteht aus einem Namespace-Index und einem numerischen, Zeichenketten-, GUID- oder opaken Identifikator. Namespace 0 ist für Standarddefinitionen reserviert; Anwendungs-Namespaces müssen beim Server registriert werden. Speichern Sie die Namespace-URI und lösen Sie deren Index für den jeweiligen Server auf, statt einen Index wie ns=2 als portabel anzusehen. Die NodeClasses sind:
Object: Organisation.
Variable: Daten.
Method: Operation.
ObjectType/VariableType: Vorlage.
DataType/ReferenceType: Definition.
View: Teilansicht.
Browse und BrowseNext navigieren durch References im AddressSpace; Read ruft Attributes ab, Call führt Methods aus. References wie Organizes, HasComponent, HasProperty und HasSubtype drücken unterschiedliche Beziehungen aus. Eine SPS kann durch ein Object mit Variables und Methods dargestellt werden. Das Browsen dieser Repräsentation belegt jedoch nicht, dass jeder Value aktuell oder beschreibbar ist.
Tabelle: Detaillierte Knotenklassen
NodeClass | Attributes / zugehörige Eigenschaften | Reference-Beispiele | Typische Dienstverwendung |
|---|---|---|---|
Object | BrowseName, DisplayName, EventNotifier | Organizes, HasComponent, HasProperty | Unterstützte Attributes durchsuchen und lesen. |
Variable | Value, DataType, ValueRank, AccessLevel | HasProperty, HasComponent | Read; Write nur, wenn unterstützt und zulässig; mit einem MonitoredItem überwachen. |
Method | Executable, UserExecutable; InputArguments und OutputArguments sind Properties | HasComponent, HasProperty | Call, sofern die Method vorhanden und autorisiert ist. |
ReferenceType | IsAbstract, Symmetric, InverseName | Organizes, HasComponent, HasSubtype | Die im Modell definierten Beziehungen durchsuchen. |
DataType | IsAbstract, DataTypeDefinition, sofern definiert | HasSubtype | Beschreibt den Wertetyp einer Variable; wird nicht mit GetEndpoints abgerufen. |
View | View-spezifische Attributes | Organizes und modelldefinierte References | Die Teilmenge durchsuchen, sofern der Server dies unterstützt. |
Vereinbaren Sie neben dem Link auch das Datenmodell. Halten Sie Namespace-URI, NodeIds, Einheiten, Qualitätsstatus, Zeitstempel und Schreibberechtigungen fest. Erfolgreiches Browsen beweist weder frische Werte noch eine sichere SPS-Aktion. Vergleichen Sie einen bekannten Prozesswert mit einer lokalen Referenz und legen Sie fest, wer schreiben darf. Der SPS/HMI-Fernzugriffsleitfaden trennt Netzwerkkonnektivität von der Erlaubnis, eine Maschine zu ändern.
Namespace, NodeId und Wertqualität dokumentieren
Eine NodeId identifiziert einen Knoten im Adressraum des Servers und enthält Namespace sowie eine numerische oder textuelle Kennung. Ein Namespace-Index kann zwischen Serverinstanzen variieren; bewahren Sie daher Namespace-URI und geprüfte NodeId auf. BrowseName und Referenzen helfen beim Auffinden, während DataValue Wert, Status und vom Server gelieferte Zeitstempel enthält. Notieren Sie Datentyp, Einheit, Skalierung und Schreibbarkeit. Ein plausibler Zahlenwert mit schlechtem Status oder altem Zeitstempel ist keine gesunde Messung.
RootFolder hat die NodeId ns=0;i=84, ObjectsFolder die NodeId ns=0;i=85. Speichern Sie für Anwendungsknoten die Namespace-URI und ermitteln Sie ihren Index zur Laufzeit.
Konfiguration und praktische Beispiele für OPC UA
Grundkonfiguration
Verwenden Sie die Konfigurationsoberfläche oder API des ausgewählten OPC-UA-Servers. Werkzeugnamen, Konfigurationsschemata und unterstützte Profile unterscheiden sich je nach Produkt und SDK. Beginnen Sie mit diesen allgemeinen Entscheidungen:
Legen Sie eine stabile ApplicationUri für die Anwendungsinstanz fest und stimmen Sie sie auf das Anwendungszertifikat ab, wenn zertifikatsbasierte Authentifizierung verwendet wird.
Konfigurieren Sie den vorgesehenen Listening-Endpunkt und Hostnamen, zum Beispiel opc.tcp://server.example:4840, und stellen Sie sicher, dass Clients die vom Server angekündigte Adresse erreichen. Ein herstellerspezifischer Pfadzusatz ist nicht allgemeingültig.
Wählen Sie eine von beiden Seiten unterstützte SecurityPolicy, einen passenden MessageSecurityMode und einen Benutzertyp. Konfigurieren Sie anschließend Vertrauen und Autorisierung. Behandeln Sie einen ungesicherten Testendpunkt als bewusste, isolierte Testeinstellung und nicht als Korrektur für den Produktionsbetrieb.
Prüfen Sie nach dem Start des Servers seine angekündigten Endpunktbeschreibungen mit GetEndpoints und einem geeigneten UA-Client. Kontrollieren Sie Hostnamen des Endpunkts, SecurityPolicy, MessageSecurityMode und Benutzer-Token-Optionen, bevor Sie eine Session aktivieren und einen bekannten Node lesen. Bei NAT oder Fernzugriff muss die angekündigte Adresse aus dem Client-Netz erreichbar bleiben.
Tabelle: Grundkonfigurationsschritte
Schritt | Vorgang | Werkzeug/Befehl | Hinweise |
|---|---|---|---|
1 | Endpunkt und Anwendungsidentität erfassen | Serverdokumentation oder unterstützter Client | Endpunkt-URL, ApplicationUri, Zertifikatsidentität und unterstützte Profile bestätigen. |
2 | Informationsmodell auflösen | Browsen oder Modellierungstool | NamespaceUri registrieren oder auslesen und den serverbezogenen NamespaceIndex auflösen; ns=1 nicht voraussetzen. |
3 | Sicherheit auswählen und bekannten Wert prüfen | Unterstützter OPC-UA-Client | Einen unterstützten MessageSecurityMode und eine SecurityPolicy getrennt auswählen; Zertifikatsvertrauen, Benutzerberechtigungen, Browse und einen dokumentierten Read prüfen. |
Prüfen Sie Routing, VLAN, VPN und Firewall der genauen Routerfirmware. Öffnen Sie keinen öffentlichen OPC-UA-Port nur für eine Vorführung; nutzen Sie einen kontrollierten Zugangspfad für den Standort. Der VLAN-Leitfaden zeigt, weshalb die Grenze einer Broadcastdomäne allein keine vollständige Zugriffspolitik ist.
Unterbrechen Sie in einem begrenzten Test nacheinander WAN, VPN, Routerversorgung und OPC-UA-Server. Erfassen Sie, wann der Client den Fehler bemerkt, ob veraltete Werte markiert werden, wie Abonnements oder Sitzungen neu verbinden und wann frische Anwendungsdaten zurückkehren.
Die OPC-UA-Dienstespezifikation beschreibt Dienstverhalten; konkrete Client- und Servereinstellungen bestimmen Zeitlimits und Wiederholungen. Ein wiederverbundener Router beweist kein wiederaufgenommenes gültiges Abonnement.
Dokumentieren Sie SPS- oder Gatewaymodell, Router, Firmware, Clientversion, Endpunkt, Vertrauenskonfiguration, Routen und Testergebnis. Steht auf einer Produktseite nur „OPC-UA-kompatibel“, fordern Sie Rolle, Profil, unterstützte Funktionen und eine Vorführung mit dem tatsächlichen Endpunkt an.
Den Pfad in sicherer Reihenfolge in Betrieb nehmen
Halten Sie Produkte und Versionen von Server und Client, Endpunkt-URL, DNS-Namen oder VPN-Gegenstelle, Port, Router-Schnittstellen, VLANs, Routen und Firewall-Regeln fest. Prüfen Sie zuerst Erreichbarkeit, dann Endpunkt-Suche, Zertifikatsvertrauen, Benutzeranmeldung, einen bekannten Leseknoten und erst danach das Abonnement. Notieren Sie den ersten Fehler in dieser Kette; ein erreichbarer TCP-Socket ist noch keine erfolgreiche OPC-UA-Prüfung. Bei NAT muss die angekündigte Endpunktadresse aus dem entfernten Clientnetz nutzbar sein.
Sicherheitszertifikat-Konfiguration
Anwendungsinstanzzertifikate können selbstsigniert oder von einer Zertifizierungsstelle ausgestellt sein. Für eine funktionierende Konfiguration benötigt die Anwendung ihren eigenen privaten Schlüssel und ihr Zertifikat und muss den Peer gemäß den konfigurierten Vertrauensregeln validieren. Ein Verzeichnis für abgelehnte Zertifikate protokolliert zurückgewiesene Zertifikate; es ist keine Liste vertrauenswürdiger Peers. Ein Bereitstellungsverfahren sollte Folgendes abdecken:
Erzeugen oder provisionieren Sie den privaten Anwendungsschlüssel und das Zertifikat oder erstellen Sie eine CSR für den gewählten CA-Ablauf. Schützen Sie den privaten Schlüssel und achten Sie auf die erwartete Anwendungsidentität.
Installieren Sie das Anwendungszertifikat sowie die erforderlichen Zertifikate vertrauenswürdiger Peers oder Aussteller in den vom gewählten SDK vorgesehenen Speichern. Prüfen Sie ein abgelehntes Zertifikat, bevor Sie ausdrücklich über Vertrauen entscheiden.
Wählen Sie eine gegenseitig unterstützte SecurityPolicy und einen passenden MessageSecurityMode und führen Sie die unterstützten Prüfungen von Gültigkeit, Identität, Vertrauenskette und Sperrstatus aus. Basic256Sha256 ist ein Policy-Name; ein Zusatz wie Basic256Sha256_RSA ist keine allgemeingültige Standardeinstellung.
Testen Sie den konfigurierten Endpunkt und die Benutzerberechtigungen mit einem bekannten schreibgeschützten Node. Dokumentieren Sie, wie Erneuerung, Sperrung und Vertrauensaktualisierungen gehandhabt werden.
Zertifikatskonfiguration (veranschaulichender Pseudocode, keine ausführbare Konfiguration eines .NET-SDK):
# Illustrative pseudocode; not a version-specific .NET SDK API
application_uri = "urn:example:opcua:server"
certificate = provision_application_certificate(application_uri)
verify_certificate_identity_and_validity(certificate, application_uri)
trust_lists = configure_trust_lists(
trusted_peers=validated_peer_certificates,
trusted_issuers=validated_issuer_certificates,
rejected_store=separate_store_for_rejected_certificates
)
endpoint = select_advertised_endpoint(
security_policy=supported_policy,
message_security_mode=supported_mode,
user_token_policy=supported_user_token
)
# Keep certificate validation enabled; resolve identity, trust, and revocation failures.Verteilen Sie öffentliche Zertifikate, Vertrauensanker und Sperrinformationen über den freigegebenen produktspezifischen Ablauf oder einen unterstützten Verwaltungsdienst. Kopieren Sie keine privaten Schlüssel in Vertrauensspeicher von Gegenstellen. Ein Verzeichniskopiervorgang oder eine LDAP-Verbindung allein verifiziert weder die Peer-Identität noch begründet sie eine sichere Vertrauensentscheidung.
Tabelle: Best Practices für Zertifikatsverwaltung
Praxis | Beschreibung | Zeitpunkt | Werkzeug/Nachweis |
|---|---|---|---|
Anwendungszertifikat provisionieren | ApplicationUri, Zertifikatsidentität, Schlüsselschutz und erforderliche Endpunktnamen prüfen. | Bei der Ersteinrichtung und beim Austausch gemäß PKI- oder Geräterichtlinie. | Standort-PKI oder unterstützter Ablauf zur Zertifikatsverwaltung. |
Vertrauen austauschen | Identität, Gültigkeit, Vertrauenskette und vorgesehenen Peer vor dem Hinzufügen zur passenden Vertrauensliste prüfen. | Vor dem Vertrauensaufbau und bei jeder Vertrauensänderung. | Dokumentierter Ablauf für Vertrauenslisten oder GDS. |
Erneuerung und Sperrprüfung | Gemäß Zertifikatsrichtlinie vor Ablauf erneuern oder neu ausstellen; Sperrstatus prüfen, sofern unterstützt und erforderlich. Ablauf und Sperrung sind unterschiedliche Sachverhalte. | Je nach Gültigkeitszeitraum, Risiko und PKI-Richtlinie; es gibt keinen allgemeinen 90-Tage- oder Jahresrhythmus. | Zertifikatsverzeichnis und unterstützter CRL-/OCSP-Prozess. |
Audit | Zertifikats-, Kanal- und Anwendungsfehler mit den unterstützten Diagnosefunktionen der Implementierung protokollieren. | Während der Inbetriebnahme und im laufenden Betrieb. | Client-/Serverdiagnose und Standortprotokollierung. |
Zertifikate und Benutzerrechte getrennt prüfen
Prüfen Sie angekündigten Server-Endpunkt, Sicherheitsrichtlinie und Nachrichtensicherheitsmodus. Bei zertifikatsbasierter Anwendungsidentität müssen Client und Server die Gegenstelle validieren und passende Vertrauens- und Ablehnungslisten pflegen; Benutzeranmeldung und Rollenrechte kommen hinzu. Beheben Sie ein unbekanntes Zertifikat nicht durch Abschalten der Prüfung. Kontrollieren Sie Hostnamen, Gültigkeit, Vertrauensentscheidung und Rechte für den betreffenden Knoten. Planen Sie Zertifikatserneuerung und Vertrauenslisten vor dem Ablauf, damit ein regulärer Wechsel die Erfassung nicht unterbricht.
Der Speicher für abgelehnte Zertifikate ist keine Vertrauensliste. Prüfen Sie Identität, Gültigkeit und Vertrauen, bevor Sie ein Zertifikat freigeben. Deaktivieren Sie die Validierung nicht, um einen Fehler zu verdecken.
Server- und Client-Konfigurationsbeispiel
Serverbeispiel (veranschaulichender Pseudocode, kein kompilierbares open62541-C): Eine Temperatur-Variable in einem registrierten Anwendungs-Namespace bereitstellen. Verwenden Sie für die tatsächlichen API-Aufrufe und den Lebenszyklus die Dokumentation der gewählten SDK-Version.
# Illustrative server pseudocode; SDK calls and types vary by version
application_uri = "urn:example:opcua:server"
model_namespace_uri = "urn:example:temperature-model"
namespace_index = server.register_namespace(model_namespace_uri)
objects_folder = NodeId(namespace_index=0, identifier=85) # ObjectsFolder
temperature_node = server.add_variable(
parent=objects_folder,
reference_type="Organizes",
node_id=NodeId(namespace_index, "Temperature", type="String"),
browse_name=QualifiedName(namespace_index, "Temperature"),
data_type="Int32",
value=initial_temperature
)
set_access(temperature_node, read=True, write=False)
start_server(advertised_endpoint, application_uri, application_certificate)
# Enable a write only in a separately approved use case with explicit permissions.Das Beispiel registriert einen Anwendungs-Namespace und fügt mit einer geeigneten Reference eine Variable unter dem standardisierten ObjectsFolder hinzu. Wert, Datentyp und Zugriffsrechte werden ausdrücklich konfiguriert. Für die vorgesehene Bereitstellung müssen außerdem Endpunkt, Anwendungszertifikat, Benutzerauthentifizierung und Berechtigungen des Servers eingerichtet werden.
Clientbeispiel (veranschaulichender Pseudocode, kein ausführbares Python-SDK-Beispiel): Lösen Sie dieselbe Namespace-URI auf und lesen Sie die konfigurierte NodeId. Ein Schreibvorgang ist im ersten Test bewusst nicht enthalten.
# Illustrative client pseudocode; not a version-specific Python API
client = connect_to_advertised_endpoint(endpoint_url, supported_security_settings)
subscription = None
try:
namespace_index = resolve_namespace_index(client, "urn:example:temperature-model")
node_id = NodeId(namespace_index, "Temperature", type="String")
data_value = read_value_and_quality(client, node_id)
verify_value_status_and_timestamps(data_value, expected_process_value)
subscription = create_subscription(client, publishing_interval=application_setting)
subscription.add_monitored_item(node_id)
process_notifications_until_planned_test_completes(subscription)
finally:
if subscription is not None:
close_subscription(subscription)
disconnect(client)
# This initial test is read-only; an approved write requires a separate step.Erstellen Sie für einen Datenänderungstest mit dem gewählten Client-SDK eine Subscription, legen Sie ein MonitoredItem für die geprüfte Variable an und verarbeiten Sie die Benachrichtigungen. Kontrollieren Sie den zurückgegebenen Status sowie gegebenenfalls angepasste Sampling- und Publishing-Einstellungen. Die Subscription-APIs der SDKs unterscheiden sich. Prüfen Sie nach einer kontrollierten Unterbrechung die Wiederherstellung von Verbindung, Session und Subscription sowie den ersten frischen DataValue.
Einen geprüften Messwert nachvollziehbar festhalten
Wählen Sie einen schreibgeschützten Knoten, dessen physischer oder SPS-Wert unabhängig prüfbar ist. Speichern Sie Namespace-URI, NodeId, Typ, Einheit, Status sowie Quell- und Serverzeitstempel, soweit vorhanden. Vergleichen Sie einen aktuellen und einen gezielt veränderten Wert, bevor Sie viele Abonnements einrichten. Bei einem Modbus-zu-UA-Gateway gehören ursprüngliches Register, Funktion, Vorzeichen, Skalierung und Byte-Reihenfolge zur Zuordnung. So trennen Sie IP-Fehler von vorhandenen, aber falsch interpretierten Tags.
Abonnements bei einer Unterbrechung beobachten
Ein Abonnement enthält überwachte Elemente und Veröffentlichungsparameter; Sitzung und sicherer Kanal gehören ebenfalls zum Ablauf. Nach WAN- oder VPN-Ausfall kann der Client je nach Produkt und Dauer neu verbinden, die Sitzung wiederherstellen oder Abonnements neu anlegen müssen. Testen Sie je einen kontrollierten Ausfall. Messen Sie Fehlererkennung, Kennzeichnung veralteter Werte, Wiederverbindung und ersten frischen Wert. Router-Failover erhält eine TCP-Sitzung nicht automatisch; ein neuer Socket stellt überwachte Elemente nicht zwangsläufig wieder her.
Den Fehler auf die betroffene Ebene eingrenzen
Ohne TCP-Verbindung prüfen Sie Namen, Mobilfunkpfad, Route, Firewall und Listener. Folgen Zertifikats- oder Benutzerfehler auf den Verbindungsaufbau, untersuchen Sie Identität, Vertrauen und Rechte. Eine erfolgreiche Sitzung mit BadNodeIdUnknown deutet auf Namespace oder NodeId; ein Wert mit altem Zeitstempel auf Servererfassung, Gateway-Zuordnung oder Client-Cache. Halten Sie Endpunkt, Statuscode und Prüfknoten ohne Zugangsdaten fest. So bleibt die Reparatur gezielt und Sicherheitskontrollen werden nicht zur Kaschierung eines Routing- oder Modellfehlers gelockert.
Pub/Sub Konfigurationsbeispiel
Eine PubSub-Konfiguration verbindet beim Publisher ein PublishedDataSet und einen DataSetWriter mit einem kompatiblen DataSetReader und einem Ziel-Mapping beim Subscriber. Der folgende Pseudocode veranschaulicht die erforderlichen Übereinstimmungen. Er ist weder eine UANodeSet-XML-Datei noch eine UADP-Nachricht oder eine importierbare Produktkonfiguration:
# Conceptual PubSub configuration outline; not XML or a runnable configuration file
publisher:
connection: select_supported_transport_and_address()
writer_group:
publishing_interval: configured_for_application
message_mapping: UADP_or_JSON_as_supported
security: configure_policy_mode_and_security_group_if_required
data_set_writer:
writer_id: configured_unique_identifier
data_set: select_fields_from_address_space()
metadata: publish_or_provision_matching_data_set_metadata()
subscriber:
connection: match_transport_and_address()
reader_group:
data_set_reader:
publisher_id: match_publisher()
writer_group_id: match_writer_group()
data_set_writer_id: match_data_set_writer()
metadata: match_data_set_schema()Konfigurieren Sie für den gewählten Transport eine Adresse oder einen Broker/Topic, der für beide Seiten erreichbar ist, und stimmen Sie PublisherId, WriterGroupId, DataSetWriterId, Feldmetadaten und Ziel-Mappings mit dem Reader ab. UDP-Multicast erfordert geeignete Netzwerkunterstützung und wird nicht automatisch über ein WAN oder VPN geroutet. Die PubSub-Nachrichtensicherheit verwendet den konfigurierten Sicherheitsmodus, die Policy und Gruppenschlüssel; ein Security Key Service kann, sofern unterstützt, Schlüssel an autorisierte Gruppenmitglieder verteilen. Transportsicherheit und PubSub-Nachrichtensicherheit sind getrennt zu entscheiden.
Tabelle: Pub/Sub-Konfigurationselemente
Element | Publisher-Konfiguration | Subscriber-Konfiguration | Prüfung/Sicherheit |
|---|---|---|---|
PublisherId | Kennzeichnet den Publisher im konfigurierten Nachrichten-Mapping. | Bei der Filterung mit der erwarteten PublisherId abgleichen. | Typ und Kodierung hängen vom Mapping ab; die Kennung ist keine Bindung an einen Verschlüsselungsschlüssel. |
WriterGroupId | Kennzeichnet die WriterGroup in der NetworkMessage. | Die erwartete WriterGroupId abgleichen, sofern erforderlich. | Nicht mit einer DataSetWriterId verwechseln. |
DataSetWriterId | Kennzeichnet einen DataSetWriter. | Die erwartete DataSetWriterId abgleichen. | Ist nicht allgemein eine „Stream-ID“; das gewählte Mapping prüfen. |
DataSet und Metadaten | Felder auswählen und DataSet-Metadaten bzw. Schema bereitstellen. | Passende Metadaten und Feldinterpretation konfigurieren. | Namespace-URIs, NodeIds, DataTypes und Feldreihenfolge prüfen. |
Transport-Mapping | Ein unterstütztes UDP-, Ethernet- oder Broker-Mapping wie MQTT auswählen, sofern anwendbar. | Ein passendes Mapping, eine Adresse bzw. ein Topic und das Reader-Verhalten konfigurieren. | AMQP, TSN und weitere Optionen hängen von der relevanten Spezifikation, dem Profil und der Produktunterstützung ab. |
Sicherheit | Bei Bedarf unterstützte Nachrichtensicherheit, SecurityGroupId und SecurityKeyServices konfigurieren. | Kompatible Sicherheitseinstellungen verwenden und Schlüssel über den konfigurierten Schlüsseldienst beziehen. | Anwendungszertifikate, Autorisierung, Schlüsselrotation und Netzwerkkontrollen separat prüfen. |
Branchenspezifische Anwendungsszenarien und Fallstudien
OPC UA kann Betriebsdaten mit Anwendungen für Produktion, Instandhaltung, Qualität und Energie verbinden, wenn ein geeignetes Informationsmodell und ein entsprechender Datenpfad implementiert sind. Die folgenden Punkte sind technische Szenarien und keine verifizierten Ergebnisse namentlich genannter Kundeninstallationen. Nutzen und Leistung müssen im tatsächlichen System bewertet werden.
Fertigung: SPS- und Maschinendaten über ein dokumentiertes Modell für MES- oder Instandhaltungsanwendungen bereitstellen; Kennungen, Einheiten, Aktualisierungsstatus und Zuständigkeiten prüfen.
Energie: Messwerte und Anlagenstatus für Überwachung und Analyse integrieren und Zeitstempel, Einheiten sowie Zugriffsrichtlinien validieren.
Pharmaindustrie: Anlagen- und Chargeninformationen zur Rückverfolgbarkeit austauschen. OPC UA begründet für sich genommen weder die Einhaltung regulatorischer Vorgaben noch die Validierung eines Produktionsdatensatzes.
Automobilindustrie: ausgewählte Informationen von Maschinen oder Robotern mit Produktions- und Instandhaltungssystemen austauschen. Anforderungen an Bewegungssteuerung, Sicherheit und Echtzeit benötigen eine eigene technische Auslegung.
Öl und Gas: Fernüberwachung über einen geeigneten Server bzw. ein Gateway und einen kontrollierten Netzwerkpfad ermöglichen; Kommunikationsverlust, Kennzeichnung veralteter Daten und Wiederherstellung testen.
Tabelle: Zusammenfassung der Anwendungsszenarien
Branche | Beispielszenario | Mögliche Rolle von OPC UA | Zu erhebende Nachweise |
|---|---|---|---|
Fertigung | Integration einer Produktionslinie | Modellierte Anlagendaten zwischen kompatiblen SPS-/MES-Anwendungen austauschen. | Unterstützte Profile, Modellzuordnung und gemessene Anwendungsergebnisse. |
Energie | Überwachung eines Umspannwerks oder Kraftwerks | Ausgewählte Messwerte und Statusinformationen für überwachende Clients bereitstellen. | Endpunktunterstützung, Aktualisierungsverhalten und Energiekennzahlen des Projekts. |
Pharmaindustrie | Rückverfolgbarkeit von Chargen und Anlagen | Eine anwendbare Informationsmodellspezifikation zur Darstellung von Anlagenparametern verwenden. | Version der Begleitspezifikation, Audit-Anforderungen und validierte Datensätze. |
Automobilindustrie | Montageautomatisierung | Ausgewählte Produktions- oder Roboterdaten austauschen, sofern die Profile zusammenpassen. | Gerätekompatibilität, Zeitmessungen und Qualitätskennzahlen des Projekts. |
Öl und Gas | Fernüberwachung | Ausgewählte Felddaten über ein geprüftes Netzwerk- und Zugriffskonzept bereitstellen. | Sicherheit, Konnektivität und gemessenes Erkennungs-/Reaktionsverhalten. |
Vergleich von OPC UA mit MQTT, Modbus, Profinet
Die Protokolle decken unterschiedliche Aufgaben in einem Industriesystem ab. OPC UA definiert Dienste und ein typisiertes Informationsmodell; MQTT verteilt Nachrichten über einen Broker; Modbus stellt eine gerätebezogene Schnittstelle auf Basis von Funktionscodes und Adressen bereit; PROFINET unterstützt Industrial-Ethernet-I/O und zugehörige Anwendungsprofile. Vergleichen Sie die erforderliche Datensemantik, Geräteunterstützung, Zeitvorgaben, Zugriffskontrolle und den Integrationsaufwand. Der Protokollname allein bestimmt weder Bandbreite noch Latenz, Sicherheit oder Kosten.
Tabelle: Protokollrollen und technische Auswahlkriterien
Merkmal | OPC UA | MQTT | Modbus | PROFINET |
|---|---|---|---|---|
Kommunikationsmodell | Client/Server-Dienste und PubSub, sofern unterstützt. | Publish/Subscribe über einen Broker. | Funktionscode-basierte Anfrage und Antwort. | Industrial-Ethernet-Profile für die Automatisierung; Einzelheiten hängen von Konformitätsklasse und Produkt ab. |
Sicherheit | UA-Sicherheitsmechanismen sind konfigurierbar; Modus, Policy, Identität, Vertrauen und Berechtigungen prüfen. | TLS sowie Broker-Authentifizierung und -Autorisierung hängen von Client, Broker und Konfiguration ab. | Modbus bietet in der Basisversion keine Anwendungsauthentifizierung oder Verschlüsselung; ein geschütztes Design oder eine unterstützte Erweiterung verwenden. | Sicherheitsfunktionen hängen von der relevanten PROFINET-Version, dem Profil und der Konfiguration ab. |
Bandbreite | Hängt von gewählter Kodierung, Feldern, Metadaten und Zeitplan ab. | Hängt von Payload, Topic, QoS und Transport ab. | Hängt von Funktion, Datenmenge und Transport ab. | Hängt von zyklischen bzw. azyklischen Daten und Netzwerkkonfiguration ab. |
Interoperabilität | Dienste und Informationsmodelle helfen; kompatible Profile und Modelle bleiben erforderlich. | Payload-Schema und Topic-Konventionen müssen abgestimmt werden. | Registerbelegung und Dateninterpretation sind gerätespezifisch. | Profile und Gerätebeschreibungen bestimmen die Interoperabilität. |
Latenz | Den ausgewählten Endpunkt, Dienst, das Netzwerk und die Last messen. | Broker-Pfad, QoS und Subscriber-Verhalten messen. | Geräteantwort und seriellen bzw. TCP-Pfad messen. | Konfiguriertes Netzwerk und Geräteklasse messen. |
Skalierbarkeit/Historie | Grenzen hängen von Server, Profil, Modell und Anwendung ab; historischer Zugriff ist ein eigener unterstützter Dienst bzw. ein eigenes Modell. | Kapazität von Broker und Verbrauchern ist implementierungsspezifisch; Historie erfordert eine separate Speicher- bzw. Anwendungsauslegung. | Grenzen von Gerät und Anwendung unterscheiden sich; ein Registerzugriff beinhaltet keine Historie. | Grenzen und Diagnosefunktionen hängen von Profilen und Geräten ab. |
Kosten | SDK, Lizenzierung, Integration und Validierung hängen von Produkt und Projekt ab. | Kosten für Broker, Clients, Hosting und Betrieb variieren. | Vorhandene Geräte können den Austauschaufwand verringern; Gateways und Integration verursachen weiterhin Kosten. | Hardware-, Engineering- und Lizenzkosten hängen von Produkt und Projekt ab. |
Typischer Einsatz | Austausch strukturierter industrieller Informationen und Dienste. | Broker-vermittelte Telemetrie und Ereignisverteilung. | Einfacher Datenaustausch mit Geräten und Integration von Altsystemen. | Kommunikation in der industriellen Automatisierung gemäß dem anwendbaren PROFINET-Profil. |
Diese Protokolle können gemeinsam eingesetzt werden. Ein geeignetes Gateway kann beispielsweise Modbus-Datenpunkte einem UA-Modell zuordnen; ein unterstütztes UA-PubSub-Mapping kann DataSets über MQTT verteilen. Routing allein führt keine dieser Konvertierungen aus. Prüfen Sie für die gewählte Kombination das konkrete Produktprofil, die Informationszuordnung, die Sicherheit und das Wiederherstellungsverhalten.
Datenrolle mit Modbus und MQTT vergleichen
Modbus stellt Datenpunkte über Funktionen und Adresskonventionen bereit. Ein OPC-UA-Server kann sie als benannte Knoten mit Typen, Einheiten und Beziehungen modellieren; die Umsetzung verlangt jedoch ein geeignetes Gateway. MQTT transportiert Nachrichten über Topics und einen Broker, definiert aber weder den OPC-UA-Adressraum noch dessen Dienste. Wählen Sie nach Aufgabe: Geräteabfrage, kontextbezogene Industriedaten oder Ereignisverteilung. Trennen Sie Protokollumsetzung von IP-Weiterleitung und VPN-Funktion des Routers.
Ausblick auf Trends
Zu den Entwicklungsthemen gehören umfangreichere Begleitmodelle, Edge-Implementierungen, die Integration von Analysen und PubSub-Transportoptionen. Strukturierte UA-Daten können digitale Zwillinge und KI-Anwendungen unterstützen, sofern diese Verbraucher das Modell verstehen. Industrieller Funk oder TSN kann Teil eines technisch ausgelegten Netzwerks sein; Anwendungszeitverhalten und Interoperabilität müssen dennoch geprüft werden. Diese Themen sind weder ein bestätigter Veröffentlichungsplan noch eine Marktprognose oder ein Beleg für eine bestimmte KI-Spezifikation.
Zu den laufenden Herausforderungen zählen die einheitliche Interpretation von Begleitmodellen, die Interoperabilität zwischen unterstützten Profilen, die Verwaltung des Zertifikats- und Schlüssellebenszyklus sowie die verfügbaren Ressourcen kleinerer Geräte. Planen Sie Aktualisierungen anhand der tatsächlich veröffentlichten Normen und der unterstützten Produktversionen, nicht anhand einer angenommenen Zahl künftiger Spezifikationen oder einer versprochenen Entwicklung der Kryptografie.
Tabelle: Zukünftige Trendvorhersage
Thema | Mögliche Entwicklung | Einordnung |
|---|---|---|
KI-bezogene Modelle | Domänendaten und Beziehungen mit definierten Informationsmodellen darstellen. | Erfordert eine konkrete Begleitspezifikation und kompatible Implementierungen; ein Gewinn bei vorausschauender Wartung ist nicht automatisch gegeben. |
Edge-Bereitstellung | Unterstützte OPC-UA-Anwendungen oder -Stacks in der Nähe von Feldgeräten ausführen. | Hardware-, SDK-Profil-, Speicher- und Leistungsgrenzen sind produktspezifisch. |
5G und TSN | OPC-UA-Anwendungen mit geeigneten Mobilfunk- oder zeitkritischen Netzwerken kombinieren. | Interoperabilität, Latenz, Abdeckung und Verfügbarkeit müssen auf Systemebene getestet werden. |
Umweltdaten | Energie- oder Umweltmessungen in einem anwendungsspezifischen Informationsmodell darstellen. | Eine grüne Spezifikation, ESG-Konformität oder Energieeinsparung ergibt sich nicht automatisch. |
Visualisierung digitaler Zwillinge | Informationsmodelle als eine Eingabe für eine Digital-Twin-Anwendung verwenden. | Visualisierung und Zusammenarbeit hängen von der Anwendungssoftware und validierten Daten ab. |
Zusammenfassung
OPC UA baut auf dem industriellen Bedarf an Datenzugriff auf, den OPC Classic adressierte, und stellt zugleich einen plattformübergreifenden AddressSpace, Dienste, Informationsmodelle und Sicherheitsmechanismen bereit. Der praktische Nutzen hängt von klaren Anwendungsrollen, kompatiblen Funktionen und einer korrekten Bereitstellung ab. Beginnen Sie mit einem bekannten schreibgeschützten Wert, prüfen Sie Identität und Berechtigungen, testen Sie die vorgesehene Subscription und Wiederherstellung und erweitern Sie anschließend das Modell. Verwenden Sie die aktuelle SDK-Dokumentation, relevante Begleitmodelle und Konformitätsnachweise für die beteiligten Produkte. Neue Analyse- und Netzwerktechnologien können diese Architektur erweitern, machen aber die Abnahme auf Anwendungsebene nicht überflüssig.
FAQ
Worin besteht der Unterschied zwischen OPC UA und OPC Classic?
OPC-Classic-Spezifikationen wie DA, HDA und AE verwenden Windows-COM/DCOM-Schnittstellen. OPC UA definiert einen plattformunabhängigen AddressSpace, Dienste, Informationsmodelle, Kommunikations-Mappings und konfigurierbare Sicherheitsmechanismen. Eine Migration ist nicht automatisch transparent: Ermitteln Sie den OPC-UA-Server (der ein Gateway sein kann) und prüfen Sie die Zuordnung von Tags, Typen und Berechtigungen.
Wie sollte mit dem Ablauf eines OPC-UA-Zertifikats umgegangen werden?
Prüfen Sie den Gültigkeitszeitraum des Zertifikats, ApplicationUri und Endpunktidentität, die Vertrauenskette, den Sperrstatus, sofern erforderlich und unterstützt, sowie die Vertrauenslisten von Server und Client. Erneuern oder ersetzen Sie das Zertifikat über die Standort-PKI oder den unterstützten Zertifikatsverwaltungsprozess und validieren sowie verteilen Sie anschließend das Ersatzzertifikat. Stellen Sie danach die Verbindung zum vorgesehenen Endpunkt her und lesen Sie einen bekannten Knoten. Benutzerrechte und das Vertrauen in das Anwendungszertifikat sind getrennte Prüfungen; schalten Sie die Validierung nicht ab. Das Deaktivieren der Sperrprüfung erneuert kein abgelaufenes Zertifikat; einen allgemeingültigen Austausch alle 90 Tage gibt es nicht.
Wann ist PubSub dem Client/Server-Modus vorzuziehen?
PubSub kommt infrage, wenn ein Publisher ausgewählte DataSet-Nachrichten an mehrere Subscriber verteilen muss und die Produkte einen kompatiblen Transport, ein passendes Mapping, Metadaten und eine geeignete Sicherheitskonfiguration unterstützen. Client/Server bleibt für Erkennung, Browsing, bedarfsabhängiges Lesen und Schreiben, Methoden und Subscriptions nützlich. PubSub kann wiederholtes Polling verringern; Vorteile bei Bandbreite und Latenz hängen jedoch von Nachrichtenauswahl, Rate, Netzwerk und Implementierung ab.
Welche Programmiersprachen lassen sich mit OPC UA verwenden?
OPC UA ist unabhängig von einer Programmiersprache spezifiziert. SDKs und Stacks sind unter anderem für C/C++, .NET, Java und Python verfügbar; ihre unterstützten Profile, Sicherheitsfunktionen und Wartung unterscheiden sich jedoch. Prüfen Sie die konkrete Bibliothek und Version anhand der Serverfunktionen, die die Anwendung benötigt.
Wie lässt sich OPC UA mit 5G einsetzen?
Eine Bereitstellung kann OPC-UA-Datenverkehr über einen unterstützten Netzwerkpfad führen, der 5G einschließt. Das Verhalten von PubSub oder Client/Server hängt weiterhin vom gewählten Mapping, Endpunkt und Netzwerkdesign ab. 5G, TSN und URLLC garantieren für sich genommen weder Latenzen unter einer Millisekunde noch drahtlose Echtzeitsteuerung; testen Sie das Gesamtsystem anhand seiner Anforderungen.
Welche OPC-UA-Konfigurationsfehler treten häufig auf und wie lassen sie sich prüfen?
Prüfen Sie zunächst den angekündigten Endpunkt und den Netzwerkpfad. Kontrollieren Sie anschließend den gewählten MessageSecurityMode und die SecurityPolicy, Zertifikatsidentität, -gültigkeit und -vertrauen, die Benutzertoken-Policy und Berechtigungen, Namespace-URI und NodeId sowie DataType und Status der Variable. Verwenden Sie Statusmeldungen und Protokolle aus der Server-/Clientdiagnose; ein Porttest oder ein allgemeines Werkzeug allein belegt nicht, dass der Anwendungsvorgang funktioniert.
Muss ein Industrierouter OPC UA decodieren, um den Verkehr zu übertragen?
Nein. Ein IP-Router kann einen erlaubten Client/Server-Datenstrom weiterleiten, ohne das OPC-UA-Datenmodell auszuwerten. Übersetzung oder lokales Hosting sind getrennt zu prüfende Fähigkeiten.
Beweist ein erreichbarer Port eine sichere, funktionierende OPC-UA-Verbindung?
Nein. Prüfen Sie Endpunktidentität, Zertifikate, Nutzerrechte, Sitzungsaufbau und einen bekannten Anwendungswert. Netzwerkerreichbarkeit ist nur ein Schritt.
Wird ein Modbus-Gerät allein durch Routing zum OPC-UA-Server?
Nein. Eine geeignete SPS oder ein Gateway muss den OPC-UA-Server bereitstellen und Modbus-Daten mit richtigen Typen, Einheiten und Bedeutungen abbilden.
Laufen OPC-UA-Abonnements nach WAN-Umschaltung automatisch weiter?
Nicht unbedingt. Client- und Servereinstellungen, Sitzungszustand und Pfadwechsel spielen eine Rolle. Testen Sie das ursprüngliche Abonnement und den ersten frischen Wert nach einer kontrollierten Unterbrechung.
Referenzen
OPC-10000-1 – OPC Unified Architecture - Part 1: Overview and Concepts — Architektur, Grundbegriffe und die Unterschiede zwischen Client/Server und PubSub.
OPC-10000-2 – OPC Unified Architecture - Part 2: Security Model — Anwendungs- und Benutzersicherheit, Zertifikatsprüfung, Vertrauen und betriebliche Zuständigkeiten.
OPC-10000-3 – OPC Unified Architecture - Part 3: Address Space Model — Knoten, Referenzen, Attribute, NodeIds und Namespace-Konzepte.
OPC-10000-4 – OPC Unified Architecture - Part 4: Services — Discovery, Sitzungen, Lese- und Schreibzugriffe, Subscriptions und Statuscodes der Dienste.
OPC-10000-5 – OPC Unified Architecture - Part 5: Information Model — Standardinformationsmodell, Namespace 0 und Definitionen der Standardordner.
OPC-10000-6 – OPC Unified Architecture - Part 6: Mappings — Kodierungen sowie Sicherheits- und Transportabbildungen.
OPC-10000-14 – OPC Unified Architecture - Part 14: PubSub — DataSet-Publisher und -Subscriber, Transportprofile und PubSub-Sicherheit.
