OPC DA und OPC UA: Unterschiede und Migration

OPC DA und OPC UA stammen beide von der OPC Foundation, sind aber unterschiedliche Protokolle. OPC DA (Data Access) gehört zu OPC Classic. Es baut auf Microsoft COM und DCOM auf, läuft deshalb unter Windows und liefert nur aktuelle Werte. OPC UA (Unified Architecture) ist eine plattformunabhängige Architektur, auch als IEC 62541 veröffentlicht, die aktuelle Werte, Alarme und Historie über einen TCP-Port mit Zertifikatssicherheit überträgt.

Wenn ein Standort ein OPC-DA-Historian- oder HMI-System durch ein OPC-UA-System ersetzt, kann der neue Client den alten Server nicht direkt ansprechen. Eine Komponente muss zwischen beiden übersetzen. Ihre Wahl entscheidet, ob Windows-Host und COM-Server auch nach der Umstellung vor Ort weiterlaufen.

OPC DA vs. OPC UA: die Unterschiede

OPC-DA-Port und DCOM

OPC DA hat keinen festen Port. Es verwendet COM auf demselben Rechner und DCOM zwischen Rechnern. Die Verbindung beginnt bei TCP-Port 135, dem RPC-Endpunktzuordner, und wechselt dann zu einem dynamisch vergebenen Port. Ab Windows Vista und Windows Server 2008 liegt der Standardbereich bei 49152 bis 65535. Ein DA-Abonnement sendet Daten vom Server an den Client zurück. Die Firewall muss DCOM deshalb in beide Richtungen zulassen.

Der Bereich lässt sich mit dem Wert Ports unter HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet einschränken. Microsoft empfiehlt mindestens 100 Ports oberhalb von 5000, weil andere Windows-Dienste denselben Bereich nutzen. DCOM schreibt IP-Adressen direkt in seine Pakete und funktioniert deshalb nicht über eine Firewall mit Adressumsetzung.

Microsofts DCOM-Härtung für CVE-2021-26414 (KB5004442) verlangt bei der DCOM-Aktivierung inzwischen die Authentifizierungsstufe für Paketintegrität (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). Sie war ab dem 14. Juni 2022 standardmäßig aktiv und lässt sich seit dem 14. März 2023 nicht mehr abschalten. Ein aktualisierter Windows-Client hebt seine Stufe automatisch an. Ein Client auf einem nicht aktualisierten Host oder mit einem DCOM-Stack außerhalb von Windows kann den Server möglicherweise nicht aktivieren. Der Server protokolliert Ereignis 10036, der Client 10037 oder 10038. Remote-DA-Verbindungen ohne diese Authentifizierung funktionieren seitdem nicht mehr. Das ist ein häufiger Anlass für die Migration.

OPC-UA-Port 4840

OPC UA verwendet ein binäres Protokoll über einen TCP-Port, standardmäßig 4840, und X.509-Anwendungszertifikate. Es ist nicht an Windows gebunden. Die IANA registriert 4840 als opcua-tcp, und ein Local Discovery Server lauscht darauf (OPC 10000-6, 7.6). Ein Server kann auf jedem Port lauschen; seine Endpunkt-URL, etwa opc.tcp://192.0.2.10:4840, nennt ihn. Die Abbildungen auf HTTPS und WebSocket nutzen 443.

Was OPC Classic umfasst

Jede Classic-Spezifikation hat einen eigenen Adressraum und eigene Dienste. OPC UA führt die drei Bereiche in einem Adressraum mit gemeinsamen Diensten zusammen (OPC 10000-1, Abschnitt 4.3).

Erfassen Sie, welche dieser drei Bereiche das bestehende System nutzt. Ein DA-Wrapper überträgt nur aktuelle Werte. Alarmquittierungen und historische Abfragen gehören nicht dazu.

Bei A&E ist besondere Sorgfalt nötig. Teil 9, Anhang D ordnet A&E-Ereigniskategorien UA-Ereignistypen zu, wenn der Wrapper ihre Bedeutung kennt. Eine Level-Bedingung namens HI HI kann beispielsweise zu einem NonExclusiveLevelAlarmType werden. Für A&E-Unterbedingungen definiert der Anhang keine allgemeine Zuordnung. Konfigurieren Sie den Wrapper für jede vom Betrieb genutzte Alarmkategorie und prüfen Sie das Ergebnis.

Drei Wege zur Migration von OPC DA zu OPC UA

Die OPC Foundation veröffentlicht einen COM UA Wrapper und einen COM UA Proxy als Beispielkomponenten (Teil 8, A.1). Kommerzielle Produkte verwenden diese Begriffe mitunter anders, und die meisten als Konverter oder Gateway von OPC DA zu OPC UA verkauften Produkte sind Wrapper. Ein „OPC-Tunneller“ überträgt beispielsweise meist DA zwischen zwei Rechnern ohne DCOM und stellt an beiden Enden DA bereit. Er beseitigt damit das DCOM-Problem, liefert aber keinen UA-Server. Halten Sie für jedes Produkt die Client- und Serverrolle auf beiden Seiten fest.

Ein Wrapper erhält die alten Abhängigkeiten: Windows-Host, DA-Server und dessen Lizenz, Dienstkonten und Startreihenfolge. Installieren Sie den Wrapper auf demselben Host wie den DA-Server. Dann bleibt COM lokal und DCOM-Verkehr muss nicht über das Netzwerk. Benennen Sie eine verantwortliche Person für den Host und planen Sie seine Updates.

Prüfen Sie die Startreihenfolge. Nach einem Windows-Neustart kann der Wrapper-Dienst vor dem DA-Server starten. Manche Wrapper versuchen die Verbindung nicht erneut; ihre Datenpunkte bleiben dann Bad, bis der Dienst neu gestartet wird.

Die DA-Version des alten Servers begrenzt die Möglichkeiten des Wrappers (Teil 8, A.3.3 und A.3.4). Bei DA 2.05a führt jedes UA Read zu einem Gerätezugriff; der Wrapper ignoriert maxAge. Ein UA-Schreibzugriff mit Statuscode oder Zeitstempel schlägt mit Bad_WriteNotSupported fehl. Bei DA 3.0 kann Read auf Gerät oder Server-Cache zugreifen; maxAge entscheidet darüber. Ein Schreibzugriff kann Wert, Qualität und Zeitstempel gemeinsam übertragen.

DA-Elemente UA-Knoten zuordnen

Erstellen Sie die Zuordnung Datenpunkt für Datenpunkt:

Teil 8, A.3.1.5 beschreibt drei Wege, eine NodeId zu erzeugen. Ein Wrapper kann den gesamten DA-Adressraum durchsuchen, eine Offline-Kopie behalten und die ItemID als Kennung verwenden. Ein anderer teilt jede ItemID an einem konfigurierten Trennzeichen und kann dasselbe nur bei Servern tun, deren ItemIDs Pfade darstellen. Ein dritter kodiert ItemID und Elementnamen gemeinsam in der NodeId. Dann stimmt die NodeId nicht mehr mit der ItemID überein und beide lassen sich nicht einfach einander zuordnen.

Aus dem DA-Element BoilerA.Flow kann beispielsweise ns=2;s=BoilerA.Flow werden. Die 2 bezeichnet eine Position im NamespaceArray des Servers, keinen festen Namen. Dieser Index kann sich mit der Wrapper-Konfiguration ändern; die Namespace-URI bleibt gleich. Speichern Sie URI und Kennung für jeden Datenpunkt und ermitteln Sie den Index bei jeder Client-Verbindung neu. Der Leitfaden zur Knotenidentität erläutert das genauer. Nehmen Sie die Wrapper-Konfiguration in das Rückfallpaket auf: Ein neu aufgebauter Wrapper mit anderen Kennungen unterbricht alle Verbraucher.

Prüfen Sie die Datentypen in Teil 8, Tabelle A.2. Die meisten entsprechen einander direkt, beispielsweise VT_R4 und Float sowie VT_I4 und Int32. VT_DATE wird jedoch Double zugeordnet, nicht DateTime. Ein DA-Datumswert kommt damit als Anzahl der Tage seit dem 30. Dezember 1899 an. Ein Verbraucher, der einen Zeitstempel erwartet, zeigt dann etwa 46289.5 als Zahl an.

Ein Element mit High-EU- und Low-EU-Eigenschaften wird zum AnalogItemType mit EURange und EngineeringUnits. Prüfen Sie die Skalierung über die gesamte Kette. Ein Durchfluss von 21,7 m³/h darf nicht zu 2,17 werden, weil der neue Datensammler eine bereits im DA-Server ausgeführte Umrechnung wiederholt.

Qualität und Zeit

Ein DA-Wert hat eine 16-Bit-Qualitätskennung. Das niederwertige Byte hat das Muster QQSSSSLL: zwei Bits für die Hauptqualität, vier für den Unterstatus und zwei für Grenzzustände. Das höherwertige Byte ist herstellerspezifisch. Häufige niederwertige Bytes sind 0xC0 (Good), 0x40 (Uncertain) und 0x00 (Bad).

Ein UA-Wert hat einen 32-Bit-StatusCode. Die obersten zwei Bits bestimmen die Schwere: 0x00000000 steht für Good, 0x40000000 für Uncertain und 0x80000000 für Bad. Teil 8, A.3.2.3 ordnet die DA-Hauptqualität der Schwere, den Unterstatus dem Untercode und die Grenzbits den Grenzbits zu. Das herstellerspezifische Byte entfällt.

Zwei Zeilen verdienen besondere Beachtung. Erstens geht das herstellerspezifische Byte verloren. Kennzeichnet ein DA-Server einen manuell eingegebenen Wert über ein Bit im höherwertigen Byte, etwa mit Qualität 0x80C0, kommt der Wert hinter dem Wrapper als einfaches Good an. Zweitens ordnet Tabelle A.3 den DA-Zustand „letzter bekannter Wert“ Bad_OutOfService zu. Versteht ein Verbraucher OutOfService als „absichtlich abgeschaltet“, kann er einen Kommunikationsfehler als geplante Abschaltung melden. Teil 8, A.1 lässt herstellerspezifische Zuordnungen zu; prüfen Sie deshalb auch die Dokumentation des Wrappers. Benötigt eine Anwendung das Herstellerbyte, vereinbaren Sie eine andere Übertragung oder dokumentieren Sie den akzeptierten Verlust.

Der Wrapper setzt den DA-Zeitstempel als UA SourceTimestamp. ServerTimestamp setzt er auf den Beginn des Read-Vorgangs (Teil 8, A.3.2.4). Der DA-Zeitstempel bezeichnet gewöhnlich den Zeitpunkt, zu dem der DA-Server den Wert zuletzt vom Gerät erhielt. Er ist nur dann die Abtastzeit des Sensors, wenn das Quellsystem ihn so definiert.

Ein Wrapper kann einen detaillierten UA-Status liefern, den der nächste Datensammler verwirft. Prüfen Sie deshalb den Datensatz im Historian- oder Analysesystem und nicht nur den Wrapper. Legen Sie vor der Umstellung fest, wie veraltete, fehlende und ungültige Werte Diagramme, Summen und Alarme beeinflussen.

Aktualisierungsraten und Deadbands

Ein DA-Client legt je Gruppe eine Aktualisierungsrate und ein prozentuales Deadband fest. Bei Wertänderungen ruft der Server den Client zurück. Im Wrapper der Foundation erzeugt ein UA MonitoredItem das DA-Abonnement. UA SamplingInterval und Deadband bestimmen den DA-Rückruf (Teil 8, A.3.5).

Der Wrapper unterstützt nur den PercentDeadband-Filter. Ein prozentuales Deadband bezieht sich auf EURange. Das DA-Element muss daher High EU und Low EU besitzen. Ohne diese Eigenschaften entsteht kein EURange und der Filter lässt sich nicht anwenden.

Ein Client, der per UA Read abfragt, nutzt diese Abonnementregeln nicht. Er erhält bei jeder Abfrage einen Wert pro Datenpunkt. Hinter einem Wrapper mit DA 2.05a löst jede Abfrage zudem einen Gerätezugriff aus. Wählen Sie das Abfrageintervall daher passend zur Last auf DA-Server und Feldnetz.

Sicherheit auf beiden Seiten

Stellen Sie den UA-Endpunkt auf SignAndEncrypt mit einer aktuellen Richtlinie ein, etwa Basic256Sha256, Aes128_Sha256_RsaOaep oder Aes256_Sha256_RsaPss. Akzeptieren Sie den Modus None nicht, selbst wenn der Wrapper ihn anbietet. Richten Sie gegenseitiges Vertrauen der Anwendungszertifikate ein und geben Sie dem Client-Benutzer nur die benötigten Rechte. Teil 2 der Spezifikation beschreibt das Sicherheitsmodell.

Zertifikate haben eine Gültigkeitsdauer. Ein abgelaufenes oder wegen einer falschen Uhr noch nicht gültiges Zertifikat führt zu Bad_CertificateTimeInvalid. Der Client liest dann keine Werte mehr, bis Zertifikat oder Uhr korrigiert wurden. Nehmen Sie das Ablaufdatum jedes Anwendungszertifikats in den Wartungsplan auf.

COM DA hat auf der DA-Seite keine eigene Benutzeridentität (Teil 8, A.2). Ein Wrapper kann einen UA-Benutzernamen und ein Passwort entgegennehmen und diesen Windows-Benutzer vor der Verbindung zum DA-Server imitieren. Viele Wrapper verbinden sich stattdessen mit ihrem eigenen Dienstkonto. Halten Sie fest, welches Windows-Konto der DA-Server sieht und welche Schreibrechte es hat. Bleibt eine DA-Verbindung remote, muss sie die oben genannte DCOM-Paketintegrität erfüllen.

Beheben Sie ein Inbetriebnahmeproblem nicht durch Abschalten der Sicherheit oder indem Sie einem reinen Lesekonto Schreibrechte geben.

Umstellung testen

Prüfen Sie vor der Migration der übrigen Datenpunkte je einen Punkt jedes Datentyps: einen skalierten Analogwert, einen Booleschen Wert und eine Zeichenfolge sowie, falls vorhanden, ein Array und einen Datumswert. Für jeden Prüfpunkt:

1. Erfassen Sie Namespace-URI und NodeId, die der Wrapper erzeugt hat.
2. Lesen Sie den Wert über DA und UA innerhalb eines DA-Abtastintervalls und vergleichen Sie ihn. Achten Sie auf doppelte Skalierung.
3. Stoppen Sie mit Freigabe das Gerät oder dessen Treiber. Erfassen Sie DA-Qualität, UA-StatusCode und die Anzeige des endgültigen Verbrauchers. Der letzte Wert darf nicht als neue Good-Probe erscheinen.
4. Starten Sie den Wrapper-Host neu. Prüfen Sie, ob die Datenpunkte ohne Änderung der Punktliste wieder Good erreichen, und messen Sie die Dauer.
5. Lesen Sie eine nicht vorhandene ItemID und versuchen Sie, in einen Punkt ohne Schreibberechtigung zu schreiben. Erwarten Sie Bad_NodeIdUnknown und Bad_NotWritable.

Betreiben Sie danach beide Wege mindestens einen vollständigen Betriebszyklus parallel, etwa eine Schicht, eine Charge oder eine Woche. Schließen Sie einen geplanten Neustart der Quelle ein. DA meldet Änderungen unter Berücksichtigung des Deadbands, während ein UA-Client abfragen kann; daher unterscheiden sich die Nachrichtenzahlen. Vergleichen Sie fortlaufend Werte und Alter des neuesten Werts. Vereinbaren Sie zulässige Abweichung und Wiederherstellungszeit vor dem Test.

Halten Sie Steuerungswege getrennt. Der alte und der neue Weg dürfen dieselbe Anlage nicht gleichzeitig ansteuern. Prüfen Sie bei jedem Schreibzugriff das physische Ergebnis. Der Leitfaden zum BACnet-Prioritätsarray zeigt, wie ein gemeinsam genutzter Befehl seinen ursprünglichen Verursacher überdauern kann.

OPC UA mit Edge

Edge auf dem ZGW-20 Gateway ist ein OPC-UA-Client. Er verbindet sich mit bis zu fünf opc.tcp-Endpunkten, nativ oder über Wrapper, aber nicht direkt mit OPC DA. Ein reines DA-System benötigt zuerst einen Wrapper.

Edge liest jeden Punkt planmäßig über Read, von einmal pro Sekunde bis einmal pro Tag. Es richtet keine Abonnements ein; die obigen Deadband-Regeln gelten daher nicht. Edge versieht jeden Wert mit der geplanten Lesezeit des Gateways, nicht mit dem SourceTimestamp. Außerdem kann Edge jeden Punkt mit eigenem Faktor und Offset skalieren. Stellen Sie diese auf 1 und 0, wenn bereits der DA-Server skaliert.

Edge akzeptiert None, Sign und SignAndEncrypt; ein neuer Endpunktplatz beginnt mit None. Stellen Sie selbst SignAndEncrypt mit Basic256Sha256 oder einer Aes-Richtlinie ein und halten Sie die Uhr des Gateways für Zertifikatsprüfungen korrekt.