Einstieg in OPC UA ── Daten von SPS und Anlagen mit einer Windows-App erfassen

Wenn Sie Daten von SPS oder Anlagen mit einer Windows-App erfassen und die Anlage einen OPC-UA-Server hat, müssen Sie unter Umständen nicht für jeden Hersteller eine eigene Kommunikation bauen. Verbinden und Werte lesen reicht allerdings nicht. Wer den Status und die Zeitstempel, die mit dem Wert zurückkommen, die Abonnements, über die Änderungen gemeldet werden, die Verbindungsfreigabe per Zertifikat und die Rückkehr nach einem Verbindungsabbruch nicht kennt, kann den erfassten Daten später nicht trauen.

Dieser Artikel erklärt die Teile von OPC UA, die man für die Datenerfassung braucht, zusammen mit den Ergebnissen, die ein C#-Client tatsächlich geliefert hat. Für den Client habe ich die .NET-Bibliothek der OPC Foundation verwendet, als Gegenstelle einen simulierten Anlagenserver. Das Verhalten mit einer bestimmten SPS oder Anlage habe ich nicht getestet. Die Einstellungen einzelner Anlagen prüfen Sie bitte in deren Unterlagen.

Das Erfassen von Bildern von GigE-Vision- und USB3-Vision-Kameras behandle ich in „Dropped Frames with GigE Vision and USB3 Vision Cameras“, Anlagen mit serieller Kommunikation in „Fallstricke bei seriellen Kommunikationsanwendungen“.

Der Unterschied zwischen OPC UA und OPC Classic

Die Spezifikationen von OPC Classic tauschen Daten zwischen Softwarekomponenten über COM/DCOM von Windows aus. OPC DA für Prozessdaten, OPC A&E für Alarme und OPC HDA für historische Daten sind als getrennte Spezifikationen festgelegt¹.

2008 veröffentlichte die OPC Foundation OPC UA (Unified Architecture). OPC UA ist eine serviceorientierte Architektur, die von keiner bestimmten Plattform abhängt, und fasst die Funktionen der einzelnen Classic-Spezifikationen zusammen. Als Gründe für die Neuentwicklung nennt die OPC Foundation unter anderem, dass Microsoft plattformübergreifende Mechanismen stärker gewichtete als COM/DCOM, dass die Technik auch auf Nicht-Microsoft-Systemen und eingebetteten Geräten laufen musste und dass sichere Verbindungen über Firewalls hinweg nötig waren¹.

Die Spezifikation von OPC UA ist auch bei der IEC als Normenreihe IEC 62541 genormt². Für die Kommunikation ist bei der IANA der Port 4840/TCP als opcua-tcp registriert³.

flowchart TB
        accTitle: Der Unterschied zwischen OPC Classic und OPC UA
        accDescr: Ein Diagramm, das zeigt, dass OPC Classic auf COM und DCOM von Windows aufbaut und in die getrennten Spezifikationen DA, A&E und HDA aufgeteilt ist, während OPC UA deren Funktionen in einer plattformunabhängigen Spezifikation zusammenfasst.
        C["OPC Classic"] --> D["Läuft auf COM/DCOM (Windows)"]
        D --> DA["Getrennte Spezifikationen DA, A&E, HDA"]
        DA -->|"Funktionen zusammenfassen"| U["OPC UA (2008)"]
        U --> P["Von keiner bestimmten Plattform abhängig"]
        P --> S["Genormt als IEC 62541"]

Abbildung 1: OPC Classic besteht aus getrennten Spezifikationen auf COM/DCOM, OPC UA fasst sie zu einer zusammen.

Gibt es in einer bestehenden Anlage nur einen OPC-DA-Server, braucht man auf der Client-Seite einen Mechanismus, der COM/DCOM verwendet. Dieser Artikel behandelt nur OPC UA.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (13 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

Der getestete Aufbau

Getestet habe ich mit folgendem Aufbau.

Die Client-Bibliothek ist die von der OPC Foundation veröffentlichte .NET-Implementierung. Für die Verwendung der 2.0-Reihe habe ich mich an Getting started im selben Repository gehalten⁴.

flowchart TB
        accTitle: Der getestete Aufbau
        accDescr: Ein Diagramm des Aufbaus, in dem sich ein C#-Client über die .NET-Bibliothek der OPC Foundation verschlüsselt mit einem simulierten asyncua-Anlagenserver verbindet, der auf Port 4840 lauscht.
        A["C#-Client (LineCollector)"] -->|"opc.tcp, SignAndEncrypt"| B["Simulierter Anlagenserver (asyncua)"]
        A -.-> L[".NET-Bibliothek der OPC Foundation 2.0.1"]
        B -.-> V["Vier Variablen unter Line1"]

Abbildung 2: Auf demselben PC verband sich der C#-Client mit dem simulierten Anlagenserver.

Der simulierte Anlagenserver

Anstelle einer Anlage habe ich mit asyncua einen kleinen Server gebaut⁵. Unter dem Objekt Line1 liegen vier Variablen: Temperatur (Temperature), Stückzahl (PartCount), in Betrieb (Running) und Sollwert (Setpoint). Die Temperatur ändert sich alle 0,5 Sekunden, die Stückzahl alle 2 Sekunden. Als Sicherheit habe ich zwei Varianten bereitgestellt: ohne Verschlüsselung (None) und mit Signatur und Verschlüsselung (SignAndEncrypt mit Basic256Sha256).

# Simulierte Anlage zum Testen. Kein Ersatz für echte Anlagen oder SPS.
import asyncio, math, random, socket
from pathlib import Path
from cryptography.x509.oid import ExtendedKeyUsageOID
from asyncua import Server, ua
from asyncua.crypto.cert_gen import setup_self_signed_certificate

HERE = Path(__file__).parent
APP_URI = "urn:komurasoft:demo-plc"


async def main():
    key, cert = HERE / "server_key.pem", HERE / "server_cert.der"
    await setup_self_signed_certificate(
        key, cert, APP_URI, socket.gethostname(),
        [ExtendedKeyUsageOID.SERVER_AUTH], {"commonName": "DemoPlcServer"})

    server = Server()
    await server.init()
    server.set_endpoint("opc.tcp://0.0.0.0:4840/demo/")
    server.set_server_name("DemoPlcServer")
    await server.set_application_uri(APP_URI)
    server.set_security_policy([
        ua.SecurityPolicyType.NoSecurity,
        ua.SecurityPolicyType.Basic256Sha256_SignAndEncrypt,
    ])
    await server.load_certificate(str(cert))
    await server.load_private_key(str(key))

    ns = await server.register_namespace("urn:komurasoft:demo-plc:line1")
    line1 = await server.nodes.objects.add_object(ua.NodeId("Line1", ns), "Line1")
    temperature = await line1.add_variable(ua.NodeId("Line1.Temperature", ns), "Temperature", 25.0)
    part_count = await line1.add_variable(
        ua.NodeId("Line1.PartCount", ns), "PartCount", ua.Variant(0, ua.VariantType.UInt32))
    await line1.add_variable(ua.NodeId("Line1.Running", ns), "Running", True)
    setpoint = await line1.add_variable(ua.NodeId("Line1.Setpoint", ns), "Setpoint", 30.0)
    await setpoint.set_writable()

    async with server:
        print("listening", flush=True)
        t, count = 0, 0
        while True:
            await asyncio.sleep(0.5)
            t += 1
            value = 25.0 + 2.0 * math.sin(t / 4) + random.uniform(-0.05, 0.05)
            await temperature.write_value(round(value, 2))
            if t % 4 == 0:
                count += 1
                await part_count.write_value(ua.Variant(count, ua.VariantType.UInt32))


asyncio.run(main())

Dieser Server akzeptiert verbundene Clients, ohne ihre Zertifikate zu prüfen. Das ist eine Testeinstellung und entspricht nicht dem Verhalten einer echten Anlage.

Der C#-Client

In die Projektdatei habe ich die folgenden zwei Pakete aufgenommen.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="OPCFoundation.NetStandard.Opc.Ua.Client" Version="2.0.1" />
    <PackageReference Include="Microsoft.Extensions.Hosting" Version="10.0.0" />
  </ItemGroup>

</Project>

Der Client verbindet sich, browst, liest, schreibt und abonniert in dieser Reihenfolge. Was die einzelnen Teile bedeuten, erkläre ich in den folgenden Abschnitten der Reihe nach.

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Opc.Ua;
using Opc.Ua.Client;
using Opc.Ua.Client.Subscriptions;
using Opc.Ua.Client.Subscriptions.Streaming;
using MonitoredItemOptions = Opc.Ua.Client.Subscriptions.MonitoredItems.MonitoredItemOptions;

string url = args.Length > 0 ? args[0] : "opc.tcp://localhost:4840/demo/";
int notifications = args.Length > 1 ? int.Parse(args[1]) : 6;
const string LineNamespace = "urn:komurasoft:demo-plc:line1";

HostApplicationBuilder builder = Host.CreateApplicationBuilder();
builder.Logging.SetMinimumLevel(LogLevel.Warning);

builder.Services
    .AddOpcUa()
    .AddClient(options =>
    {
        options.ApplicationName = "LineCollector";
        options.ApplicationUri = "urn:localhost:LineCollector";
        options.ProductUri = "urn:komurasoft:LineCollector";
        options.PkiRoot = Path.Combine(AppContext.BaseDirectory, "pki");
    })
    .AddDiscoveryAndConnect(options =>
    {
        options.DiscoveryUrl = url;
        options.SecurityMode = MessageSecurityMode.SignAndEncrypt;
        options.SecurityPolicyUri = SecurityPolicies.Basic256Sha256;
    });

using IHost host = builder.Build();
await host.StartAsync();
using var timeout = new CancellationTokenSource(TimeSpan.FromMinutes(2));
CancellationToken ct = timeout.Token;

try
{
    var connect = host.Services
        .GetRequiredService<Func<CancellationToken, Task<ManagedSession>>>();
    ManagedSession session = await connect(ct);
    await using (session)
    {
        Console.WriteLine($"接続: {session.ConfiguredEndpoint?.EndpointUrl}");

        // Den Namespace-Index legt der Server fest. Aus der URI nachschlagen und daraus NodeIds bilden
        ushort ns = (ushort)session.NamespaceUris.GetIndex(LineNamespace);
        var line1 = new NodeId("Line1", ns);
        var temperature = new NodeId("Line1.Temperature", ns);
        var partCount = new NodeId("Line1.PartCount", ns);
        var setpoint = new NodeId("Line1.Setpoint", ns);

        // Browse: die Variablen unter Line1 auflisten
        var browser = new Browser(session)
        {
            BrowseDirection = BrowseDirection.Forward,
            ReferenceTypeId = ReferenceTypeIds.HierarchicalReferences,
            IncludeSubtypes = true,
            NodeClassMask = (uint)NodeClass.Variable,
        };
        Console.WriteLine("Line1 の変数:");
        foreach (ReferenceDescription child in await browser.BrowseAsync(line1, ct))
        {
            Console.WriteLine($"  {child.DisplayName}  {child.NodeId}");
        }

        // Lesen: nicht nur den Wert, sondern auch den Status und die beiden Zeitstempel ansehen
        DataValue t = await session.ReadValueAsync(temperature, ct);
        Console.WriteLine($"Temperature = {t.WrappedValue}  状態 {t.StatusCode}");
        Console.WriteLine($"  Source {Hms(t.SourceTimestamp)} / Server {Hms(t.ServerTimestamp)}");

        // Liest man einen nicht vorhandenen Knoten, kommt statt eines Werts ein Bad-Status zurück
        try
        {
            await session.ReadValueAsync(new NodeId("Line1.Pressure", ns), ct);
        }
        catch (ServiceResultException ex)
        {
            Console.WriteLine($"Line1.Pressure の読み取り: {ex.StatusCode}");
        }

        // Schreiben: Setpoint auf 32.5 setzen
        var write = new WriteValue
        {
            NodeId = setpoint,
            AttributeId = Attributes.Value,
            Value = new DataValue(new Variant(32.5)),
        };
        WriteResponse wr = await session.WriteAsync(null, new[] { write }, ct);
        Console.WriteLine($"Setpoint の書き込み: {wr.Results[0]}");

        // Abonnieren: den Server um Abtastung alle 500 ms bitten und sich Änderungen melden lassen
        Console.WriteLine($"購読({notifications}件まで):");
        await foreach (DataValueChange change in session.DefaultStreaming
            .SubscribeDataChangesAsync(new[] { temperature, partCount }, options: new MonitoredItemOptions
            {
                SamplingInterval = TimeSpan.FromMilliseconds(500),
                QueueSize = 5,
            }, ct: ct)
            .TakeAsync(notifications)
            .WithCancellation(ct))
        {
            DataValue v = change.Value;
            string name = change.MonitoredItem?.Name.Split("s=")[^1] ?? "?";
            Console.WriteLine($"  {Hms(v.SourceTimestamp)}  {name,-17} {v.WrappedValue,6}  {v.StatusCode}");
        }
    }
}
catch (ServiceResultException ex)
{
    Console.Error.WriteLine($"OPC UA エラー {ex.StatusCode}: {ex.Message}");
    Environment.ExitCode = 1;
}
finally
{
    await host.StopAsync();
}

static string Hms(DateTimeUtc time) => time.ToDateTime().ToString("HH:mm:ss.fff");

Beim ersten Start kam keine Verbindung zustande. Den Grund erkläre ich im Abschnitt „Verbindungen per Zertifikat freigeben“. Die folgende Ausgabe entstand, nachdem ich dem Zertifikat des Servers vertraut hatte. Die Warnprotokolle der Bibliothek habe ich weggelassen.

接続: opc.tcp://localhost:4840/demo/
Line1 の変数:
  Temperature  ns=2;s=Line1.Temperature
  PartCount  ns=2;s=Line1.PartCount
  Running  ns=2;s=Line1.Running
  Setpoint  ns=2;s=Line1.Setpoint
Temperature = 23.09  状態 Good [0x00000000]
  Source 13:40:51.302 / Server 13:40:51.302
Line1.Pressure の読み取り: BadNodeIdUnknown [0x80340000]
Setpoint の書き込み: Good [0x00000000]
購読(6件まで):
  13:40:51.302  Line1.Temperature  23.09  Good [0x00000000]
  13:40:50.801  Line1.PartCount       67  Good [0x00000000]
  13:40:51.802  Line1.Temperature  23.05  Good [0x00000000]
  13:40:52.304  Line1.Temperature  23.07  Good [0x00000000]
  13:40:52.806  Line1.Temperature   23.2  Good [0x00000000]
  13:40:52.806  Line1.PartCount       68  Good [0x00000000]

Die Uhrzeiten sind UTC.

Anlagendaten erscheinen als Knoten im Adressraum

Ein OPC-UA-Server stellt seine Daten als Sammlung von Knoten bereit. Diese Sammlung heißt Adressraum. Es gibt verschiedene Arten von Knoten, etwa Objekte, die Ordner oder Anlagen darstellen, und Variablen, die Werte haben, und die Knoten sind über Referenzen miteinander verbunden. Der Client folgt den Referenzen mit dem Dienst Browse und ermittelt so, welche Knoten es gibt⁶.

In der Ausgabe oben folgt der Client von Line1 aus den hierarchischen Referenzen und findet die vier Variablen.

flowchart TB
        accTitle: Der Adressraum der simulierten Anlage
        accDescr: Ein Diagramm, das zeigt, dass unter dem Ordner Objects das Objekt Line1 liegt und darunter die vier Variablen Temperature, PartCount, Running und Setpoint.
        O["Objects"] --> L["Line1 (Objekt)"]
        L --> T["Temperature (Variable)"]
        L --> P["PartCount (Variable)"]
        L --> R["Running (Variable)"]
        L --> S["Setpoint (Variable, beschreibbar)"]

Abbildung 3: Der Adressraum der simulierten Anlage. Der Client findet die Knoten, indem er mit Browse den Referenzen folgt.

Eine NodeId besteht aus Namespace und Bezeichner

Knoten werden über die NodeId identifiziert. ns=2;s=Line1.Temperature in der Ausgabe bedeutet, dass der Namespace-Index 2 ist und der Bezeichner die Zeichenkette Line1.Temperature.

Hinter einem Namespace steht eine URI. Die Spezifikation legt fest, dass Namespace-URIs innerhalb der Dienste als Zahlen dargestellt werden und diese Zahl der Position im NamespaceArray des Servers entspricht. Index 0 ist der OPC-UA-Namespace http://opcfoundation.org/UA/⁷.

Deshalb schreibt man den Indexwert nicht fest in den Code, sondern schlägt den Index aus der URI nach. Im Code oben ermittelt session.NamespaceUris.GetIndex(LineNamespace) aus der URI die 2, und daraus werden die NodeIds gebildet.

flowchart TB
        accTitle: Wie aus einer Namespace-URI eine NodeId entsteht
        accDescr: Ein Diagramm, das zeigt, dass der Client die Namespace-URI im NamespaceArray des Servers nachschlägt, den Index erhält und aus diesem Index und dem Bezeichner die NodeId bildet.
        U["Namespace-URI"] --> A["NamespaceArray des Servers"]
        A --> I["Index (in diesem Beispiel 2)"]
        I --> N["NodeId ns=2;s=Line1.Temperature"]
        K["Bezeichner Line1.Temperature"] --> N

Abbildung 4: Den Namespace-Index aus der URI nachschlagen und mit dem Bezeichner zur NodeId kombinieren.

Lesen und Schreiben liefern mit dem Wert auch Status und Zeitstempel

Die Werte von Variablen werden mit den Diensten Read und Write gelesen und geschrieben⁸. Beim Lesen kommt nicht nur der Wert zurück. In einer Struktur namens DataValue kommen Wert, Statuscode, Quellzeitstempel und Serverzeitstempel zurück⁹.

Die oberen zwei Bits des Statuscodes bedeuten Good (Erfolg), Uncertain (teilweiser Erfolg, je nach Zweck nicht verwendbar) oder Bad (Fehler)¹⁰. Good [0x00000000] in der Ausgabe ist Good.

Beim Lesen des nicht vorhandenen Line1.Pressure kam statt eines Werts BadNodeIdUnknown [0x80340000] zurück. ReadValueAsync dieser Bibliothek löst bei einem Bad-Status eine Ausnahme aus⁴. Wenn ein System Werte aufzeichnet und den Statuscode neben dem Wert mitspeichert, lassen sich die Werte, die während eines Bad-Status aufgezeichnet wurden, später unterscheiden.

flowchart TB
        accTitle: Der Inhalt eines DataValue
        accDescr: Ein Diagramm, das zeigt, dass ein DataValue, wie er beim Lesen und bei Benachrichtigungen zurückkommt, vier Teile hat, Wert, Statuscode, Quellzeitstempel und Serverzeitstempel, und dass der Wert bei einem Bad-Statuscode ignoriert wird.
        D["DataValue"] --> V["Wert"]
        D --> S["Statuscode"]
        D --> TS["SourceTimestamp (Zeit der Quelle)"]
        D --> TV["ServerTimestamp (Zeit des Servers)"]
        S -->|"bei Bad"| X["Wert ignorieren"]

Abbildung 5: Ein Leseergebnis enthält nicht nur den Wert, sondern auch einen Statuscode und zwei Zeitstempel.

Beim Schreiben habe ich 32.5 in Setpoint geschrieben, und als Statuscode des Ergebnisses kam Good zurück. Ob eine Variable beschreibbar ist, entscheidet der Server. In diesem simulierten Server ist nur Setpoint beschreibbar. Ob man die Sollwerte einer Anlage von außen ändern können soll, betrifft das Sicherheitskonzept der Anlage und wird in diesem Artikel nicht behandelt.

Änderungen melden lassen: Abonnements und MonitoredItems

Um Änderungen von Werten zu verfolgen, kann der Client Read in einem festen Intervall wiederholen. OPC UA hat daneben einen Mechanismus, der die Überwachung der Werte dem Server überlässt und sich Änderungen melden lässt: Abonnements (Subscriptions) und MonitoredItems.

Ein MonitoredItem ist ein einzelnes überwachtes Ziel und hat ein Abtastintervall. Das Abtastintervall ist das schnellste Intervall, in dem der Server Werte von der Quelle abtastet, und gilt in der Spezifikation als „Best-Effort“-Zyklus¹¹. Erfüllt eine Abtastung die Bedingung des Filters, entsteht eine Benachrichtigung. Ohne Filter wird benachrichtigt, wenn sich der Wert oder der Status ändert¹².

Benachrichtigungen kommen zunächst in die Warteschlange des MonitoredItem. Für den Fall, dass die Warteschlange überläuft, legt man fest, ob die ältesten oder die neuesten verworfen werden, und ab einer Warteschlangengröße von 2 wird im Statuscode das Overflow-Bit gesetzt, das das Verwerfen anzeigt¹³.

Ein Abonnement fasst mehrere MonitoredItems zusammen und sendet in jedem Publishing-Intervall die noch nicht gesendeten Benachrichtigungen an den Client. Folgen Zyklen ohne Benachrichtigungen aufeinander, sendet es Keep-alives, die anzeigen, dass das Abonnement noch lebt¹⁴.

flowchart TB
        accTitle: Der Ablauf von Abonnements und MonitoredItems
        accDescr: Ein Diagramm, das zeigt, dass ein MonitoredItem die Werte der Quelle im Abtastintervall abtastet, die Benachrichtigungen, die den Filter passieren, in eine Warteschlange stellt und das Abonnement sie im Publishing-Intervall gesammelt an den Client sendet und Keep-alives sendet, wenn es keine Benachrichtigungen gibt.
        S["Quelle (Werte der Anlage)"] --> M["MonitoredItem"]
        M -->|"Abtastintervall"| F["Filter (Standard: Änderung von Wert oder Status)"]
        F --> Q["Warteschlange (bei Überlauf Overflow)"]
        Q --> SUB["Abonnement"]
        SUB -->|"Publishing-Intervall"| C["Client"]
        SUB -.->|"ohne Benachrichtigungen"| K["Keep-alive"]

Abbildung 6: Das MonitoredItem tastet ab und sammelt in der Warteschlange, das Abonnement sendet gesammelt an den Client.

Im Code oben habe ich Temperature und PartCount mit einem Abtastintervall von 500 Millisekunden und einer Warteschlangengröße von 5 abonniert¹⁵. In der Ausgabe kommt die Temperatur etwa alle 0,5 Sekunden, die Stückzahl etwa alle 2 Sekunden. Die ersten beiden Einträge waren die Werte, die die Variablen zum Beginn des Abonnements hatten. 13:40:50.801 bei der Stückzahl ist die Zeit, zu der sich der Wert vor Beginn des Abonnements geändert hatte. Bei den Benachrichtigungen wird der Quellzeitstempel angezeigt, also nicht die Empfangszeit der Benachrichtigung, sondern die Zeit, zu der sich der Wert geändert hat.

Wiederholtes Lesen oder Abonnement

Beim wiederholten Lesen bestimmt der Client das Intervall, und der Mechanismus ist einfach. Dafür gehen Anfrage und Antwort jedes Mal hin und her, auch wenn sich der Wert nicht geändert hat, und Änderungen, die kürzer als das Intervall sind, werden übersehen. Beim Abonnement tastet der Server ab und sendet nur Änderungen, sodass auch bei Werten, die sich selten ändern, der Datenverkehr kaum wächst. Auch beim Abonnement werden Änderungen, die kürzer als das Abtastintervall sind, aber womöglich nicht gemeldet. Die Spezifikation erlaubt eine schnellere Abtastung als angegeben, verlangt sie aber nicht¹¹.

flowchart TB
        accTitle: Der Unterschied zwischen wiederholtem Lesen und Abonnement
        accDescr: Ein Diagramm, das zeigt, dass beim wiederholten Lesen der Client das Intervall bestimmt und jedes Mal anfragt, beim Abonnement der Server im Abtastintervall abtastet und nur Änderungen sendet, und dass beide Änderungen, die kürzer als das Intervall sind, unter Umständen nicht erfassen.
        A["Änderungen eines Werts verfolgen"] --> R["Wiederholt lesen"]
        A --> S["Abonnieren"]
        R --> R1["Client bestimmt das Intervall, fragt jedes Mal an"]
        S --> S1["Server tastet ab, sendet nur Änderungen"]
        R1 --> X["Änderungen kürzer als das Intervall gehen eventuell verloren"]
        S1 --> X

Abbildung 7: Mit beiden Methoden können Änderungen, die kürzer als das Intervall sind, verloren gehen.

Verbindungen per Zertifikat freigeben

Bei einer OPC-UA-Verbindung wählt man den Schutzgrad der Nachrichten mit MessageSecurityMode. Die Werte sind None ohne Schutz, Sign nur mit Signatur und SignAndEncrypt mit Signatur und Verschlüsselung¹⁶. Die Kombination der Algorithmen für Signatur und Verschlüsselung legt die Sicherheitsrichtlinie fest. In diesem Artikel habe ich Basic256Sha256 verwendet.

Für Signatur und Verschlüsselung verwendet jede Anwendung ein eigenes Zertifikat. Client und Server prüfen gegenseitig ihre Zertifikate und lehnen Verbindungen mit Gegenstellen ab, denen sie nicht vertrauen. Ein Server, der mit der .NET-Bibliothek der OPC Foundation gebaut ist, bietet die unverschlüsselte Richtlinie None standardmäßig nicht an⁴.

Die erste Verbindung scheiterte mit BadCertificateUntrusted

Beim ersten Lauf vertraute der Client dem Zertifikat des Servers nicht, und die Verbindung wurde abgelehnt. Ein Auszug aus der Ausgabe:

fail: Opc.Ua.CertificateValidationCore[91]
      Certificate [Subject=CN=DemoPlcServer, CN=urn:komurasoft:demo-plc, Thumbprint=4E236DDA629FE2AB32D185BF681609FD6C525363, NotBefore=2026-11-01, NotAfter=2027-11-01, KeyAlgorithm=1.2.840.113549.1.1.1] validation failed with suppressible errors but was rejected. Reason=Id: BadCertificateUntrusted
...
OPC UA エラー BadCertificateUntrusted [0x801A0000]: [801A0000] (BadCertificateUntrusted) 'Could not verify security on OpenSecureChannel response.'

Diese Bibliothek speichert abgelehnte Zertifikate im Speicher rejected. Verschiebt ein Administrator sie von dort in den Speicher trusted, vertraut die Bibliothek dieser Gegenstelle¹⁷. Hier habe ich das Zertifikat des Servers aus pki/rejected/certs nach pki/trusted/certs verschoben, erneut ausgeführt und konnte mich verbinden. Vor dem Verschieben prüft man den Fingerabdruck, der auch im Dateinamen steht, mit dem Administrator des Servers⁴.

flowchart TB
        accTitle: Der Weg bis zum Vertrauen in ein Zertifikat
        accDescr: Ein Diagramm, das zeigt, dass der Client bei der ersten Verbindung das Zertifikat des Servers ablehnt und im Speicher rejected ablegt und dass er nach Prüfung des Fingerabdrucks und dem Verschieben in den Speicher trusted bei der nächsten Verbindung vertraut und sich verbinden kann.
        A["Erste Verbindung"] --> B["BadCertificateUntrusted"]
        B --> C["Zertifikat im Speicher rejected abgelegt"]
        C --> D["Fingerabdruck mit dem Server-Administrator prüfen"]
        D --> E["In den Speicher trusted verschieben"]
        E --> F["Nächste Verbindung: Vertrauen und Verbindung"]

Abbildung 8: Wer ein abgelehntes Zertifikat prüft und nach trusted verschiebt, vertraut dieser Gegenstelle.

Es gibt auch die Einstellung AutoAcceptUntrustedCertificates, die nicht vertrauenswürdige Zertifikate automatisch akzeptiert. Der Standard ist false, und die Unterlagen der Bibliothek schreiben, dass sie in Entwicklungsumgebungen nützlich ist, in der Produktion aber nicht verwendet werden sollte¹⁷.

NotAfter=2027-11-01 im Protokoll ist das Ablaufdatum des Zertifikats des simulierten Servers. Es ist ein selbstsigniertes Zertifikat, das mit der asyncua-Funktion erzeugt wurde, und lief ein Jahr nach dem Erstellungsdatum ab. Auch die Zertifikate von Anlagen haben ein Ablaufdatum, deshalb legen Sie im Betrieb ein Verfahren fest, mit dem Sie sie vor dem Ablauf austauschen und die Gegenstelle ihnen vertrauen lassen. Den Umgang mit dem Windows-Zertifikatspeicher fasse ich in „Windows-Zertifikatspeicher in der Praxis“ zusammen.

Authentifizierung des Benutzers

Mit Zertifikaten werden Anwendungen gegenseitig geprüft. Unabhängig davon übergibt man beim Öffnen einer Sitzung ein Token, das den Benutzer ausweist. Die Spezifikation kennt vier Arten: anonym, Benutzername und Passwort, X.509-Zertifikat und extern ausgestellte Tokens¹⁸. Der Client hier hat sich anonym verbunden. Welche Tokens ein Server akzeptiert, steht in den Informationen der Endpunkte des Servers¹⁹.

Wo die Datenerfassung in der Praxis hakt

Im Folgenden nenne ich, gestützt auf das Experiment und die Spezifikation, Probleme, die bei Systemen zur Erfassung von Anlagendaten häufig auftreten.

Werte aus der Zeit, in der der Server stand, kommen nicht an

Während des Abonnements habe ich den Server angehalten und nach etwa 15 Sekunden neu gestartet. ManagedSession dieser Bibliothek verbindet sich bei einem Verbindungsabbruch automatisch neu²⁰. Während der Server stand, versuchte der Client immer wieder, sich neu zu verbinden.

warn: Opc.Ua.ChannelManager[6]
      Reconnect failed. Endpoint=opc.tcp://localhost:4840/demo/, Attempt=3, Outcome=transient-failure, Status=BadNotConnected, ErrorMessage=Could not connect to the remote endpoint.

Als der Server zurück war, kamen auch die Benachrichtigungen zurück. Ein Auszug aus der Ausgabe des Abonnements:

  13:41:13.364  Line1.Temperature  25.61  Good [0x00000000]
  13:41:13.865  Line1.Temperature  25.12  Good [0x00000000]
  13:41:34.285  Line1.Temperature  26.55  Good [0x00000000]
  13:41:33.784  Line1.PartCount        2  Good [0x00000000]
  13:41:34.786  Line1.Temperature  26.16  Good [0x00000000]

Von 13:41:13 bis 13:41:34 ist kein einziger Wert angekommen. Die Stückzahl ist von 78 auf 2 zurückgegangen. Das liegt daran, dass der simulierte Server neu gestartet wurde und wieder bei 0 zu zählen begann.

In diesem Beispiel stand der Server selbst, deshalb sind die Werte aus dieser Zeit nirgends gespeichert. Der Wiederverbindungsmechanismus stellt die Verbindung wieder her, füllt aber die Werte aus der Ausfallzeit nicht nachträglich auf.

Anders ist es, wenn nur die Kommunikation unterbrochen war und der Server weiterlief. Die Spezifikation hat den Dienst Republish, mit dem man sich nicht angekommene Benachrichtigungsnachrichten aus der Wiederholungswarteschlange des Servers erneut senden lässt²¹. Auch in der Warteschlange des MonitoredItem sammeln sich Benachrichtigungen, aber was über die Warteschlangengröße hinausgeht, wird verworfen¹³. Diesen Fall habe ich im Experiment nicht getestet. In beiden Fällen sollten Sie die Zeiten von Verbindungsabbruch und Wiederverbindung aufzeichnen, damit erkennbar ist, in welchem Zeitraum keine Werte kamen. Wiederverbindung und Log-Design bei Anlagen mit serieller Kommunikation behandle ich auch in „Fallstricke bei seriellen Kommunikationsanwendungen“.

flowchart TB
        accTitle: Aufzeichnung beim Anhalten des Servers
        accDescr: Ein Diagramm, das zeigt, dass der Client bei angehaltenem Server während des Abonnements wiederholt versucht, sich neu zu verbinden, dass mit der Rückkehr des Servers auch die Benachrichtigungen zurückkommen, die Werte aus der Ausfallzeit aber nicht ankommen, weshalb man die Zeiten von Verbindungsabbruch und Wiederverbindung aufzeichnet.
        A["Während des Abonnements"] --> B["Server stoppt"]
        B --> C["Client versucht wiederholt neu zu verbinden"]
        C --> D["Server zurück, Benachrichtigungen auch"]
        B -.-> E["Werte aus der Ausfallzeit kommen nicht an"]
        E -.-> F["Zeiten von Abbruch und Wiederverbindung aufzeichnen"]

Abbildung 9: Die Wiederverbindung stellt die Verbindung her, aber die Werte aus der Ausfallzeit kommen nicht an.

Welchen Zeitstempel man aufzeichnet

Laut Spezifikation ist der SourceTimestamp die Zeit, die die Datenquelle dem Wert gegeben hat, und soll die Zeit angeben, zu der sich der Wert geändert hat. Der ServerTimestamp ist die Zeit, zu der der Server den Wert erhalten hat oder wusste, dass er korrekt ist⁹. Der simulierte Server hier erzeugt die Werte selbst, deshalb waren beide Zeiten gleich.

Wenn Sie wissen wollen, wann sich der Wert in der Anlage geändert hat, verwenden Sie den SourceTimestamp. Diese Zeit wird aber mit der Uhr der Quelle gesetzt, und geht die Uhr der Anlage oder des Servers falsch, ist auch die Aufzeichnung verschoben. Wenn Sie die erfassten Daten mit anderen Aufzeichnungen abgleichen, speichern Sie die Zeit des empfangenden PCs daneben, dann können Sie die Abweichung später prüfen. Die Zeitsynchronisation auf der Windows-Seite fasse ich in „Windows-Zeitsynchronisation (w32time) und Unternehmenssysteme“ zusammen.

Werte mit einem anderen Status als Good nicht einfach als Zahlen behandeln

Bei einem Bad-Statuscode soll der Wert ignoriert werden⁹. Bei Uncertain ist der Wert je nach Zweck nicht verwendbar¹⁰. Sortieren Sie die Werte vor Diagrammen und Auswertungen nach dem Statuscode und legen Sie fest, wie Werte behandelt werden, die nicht Good sind. Auch das Overflow-Bit bei einem Warteschlangenüberlauf wird im Statuscode gesetzt¹³. Wie man den Zustand von Anlagen auf dem Bildschirm darstellt, behandle ich in „Best Practices für die Prüfung und Anzeige des Zustands externer Geräte“.

Den Port in der Firewall öffnen

Der bei der IANA registrierte Port für OPC UA ist 4840/TCP³. Allerdings verwenden nicht alle Server diese Nummer. Die .NET-Beispiele der OPC Foundation verwenden unter anderem den Port 62541⁴. Prüfen Sie die Portnummer in der Endpunkt-URL der Anlage und erlauben Sie Verbindungen zu diesem Port. Läuft der Server unter Windows, geschieht das in dessen Windows-Firewall, und liegt Netzwerktechnik dazwischen, auf diesen Geräten. Wie man eingehende Regeln anlegt, fasse ich in „Windows-Firewall und Fachanwendungen“ zusammen.

flowchart TB
        accTitle: Wo die Datenerfassung hakt
        accDescr: Ein Diagramm, das die Stellen, an denen die Erfassung von Anlagendaten hakt, aufteilt in den Inhalt der Aufzeichnung (Werte aus der Ausfallzeit des Servers kommen nicht an, welcher Zeitstempel aufgezeichnet wird, Umgang mit Werten, die nicht Good sind) und die Vorbereitung der Verbindung (Port in der Firewall, Ablauf der Zertifikate).
        A["Wo die Datenerfassung hakt"] --> R["Inhalt der Aufzeichnung"]
        A --> N["Vorbereitung der Verbindung"]
        R --> B["Werte aus der Ausfallzeit fehlen"]
        B ~~~ C["Welcher Zeitstempel"]
        C ~~~ D["Umgang mit Werten außer Good"]
        N --> E["Port in der Firewall"]
        E ~~~ F["Ablauf der Zertifikate"]

Abbildung 10: Auch wenn die Verbindung steht, prüfen Sie Lücken in der Aufzeichnung, Zeiten, Status, Ports und Zertifikate.

Abgrenzung zu Modbus/TCP und herstellereigenen Protokollen

Für die Kommunikation mit SPS und Anlagen gibt es neben OPC UA auch Modbus/TCP und Protokolle, die der SPS-Hersteller bereitstellt.

Die Modbus-Spezifikation behandelt Daten in vier Tabellen: schreibgeschützte 1-Bit-Discrete-Inputs, lesbare und beschreibbare 1-Bit-Coils, schreibgeschützte 16-Bit-Input-Register und lesbare und beschreibbare 16-Bit-Holding-Register²². Bei der IANA ist 502/TCP für das Modbus-Anwendungsprotokoll (mbap) registriert³.

In diese Tabellen passen nur Bits und 16-Bit-Wörter, deshalb prüft man in den Unterlagen der Anlage, welcher Wert in welchem Format an welcher Adresse liegt, und hinterlegt das auf der Client-Seite. Bei OPC UA stellt der Server, wie gesehen, benannte Variablen im Adressraum bereit, und der Client kann sie mit Browse ermitteln. Zu den Werten gehören Statuscode und Zeitstempel, und die Verbindung wird per Zertifikat freigegeben.

Was man verwendet, hängt oft davon ab, was die Anlage anbietet. Hat die Anlage einen OPC-UA-Server, nutzt man ihn; gibt es nur Modbus/TCP, erstellt man eine Adresszuordnung und liest danach. Gibt es nur das Herstellerprotokoll oder ein SDK, folgt man dessen Unterlagen. Wie man den Kommunikationsweg mit USB-Geräten wählt, fasse ich in „USB-Geräte aus einer Windows-App ansprechen“ zusammen.

flowchart TB
        accTitle: Den Kommunikationsweg zur Anlage wählen
        accDescr: Ein Diagramm, das zeigt, dass man bei einer Anlage mit OPC-UA-Server die Variablen per OPC UA browst und erfasst, bei nur Modbus/TCP Adressen und Formate in den Unterlagen prüft und die Register liest und bei nur einem Herstellerprotokoll dessen Unterlagen folgt.
        A["Kommunikation, die die Anlage anbietet"] --> B{"Was gibt es?"}
        B -->|"OPC-UA-Server"| C["Variablen browsen und erfassen"]
        B -->|"Nur Modbus/TCP"| D["Adressen und Formate in den Unterlagen prüfen"]
        B -->|"Nur Herstellerprotokoll"| E["Unterlagen und SDK des Herstellers folgen"]
        D --> F["Register lesen und in Werte umrechnen"]

Abbildung 11: Womit man erfasst, hängt oft davon ab, was die Anlage anbietet.

Verwandte Artikel

• Dropped Frames with GigE Vision and USB3 Vision Cameras — Locating the Cause and the Windows Settings to Review
• Fallstricke bei seriellen Kommunikationsanwendungen — von der Wiederverbindung bis zum Log-Design
• Best Practices für die Prüfung und Anzeige des Zustands externer Geräte
• USB-Geräte aus einer Windows-App ansprechen
• Windows-Firewall und Fachanwendungen
• Windows-Zertifikatspeicher in der Praxis
• Windows-Zeitsynchronisation (w32time) und Unternehmenssysteme

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Dies sind Themenseiten, die zu diesem Thema passen. Ausgehend vom Artikel gelangen Sie zu verwandten Leistungen und weiteren Artikeln.

Leistungen zu diesem Thema

Dieser Artikel führt zu den folgenden Leistungsseiten. Beginnen Sie gern mit einem Einstieg, der Ihrem Anliegen nahekommt.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist der Unterschied zwischen OPC UA und OPC Classic (OPC DA)?

OPC Classic ist eine Spezifikation, die Daten über COM/DCOM von Windows austauscht. OPC UA ist eine 2008 veröffentlichte Spezifikation, die von keinem bestimmten Betriebssystem abhängt und die Funktionen von Classic zusammenfasst. OPC-UA-Clients laufen auch außerhalb von Windows, und eine DCOM-Konfiguration ist nicht nötig.

Reicht es, die Werte bei OPC UA in einem festen Intervall zu lesen?

Wenn es wenige Werte sind und das Intervall lang ist, kann man sie auch durch Lesen erfassen. Will man Änderungen der Werte verfolgen, kann man die Abtastung per Abonnement dem Server überlassen und sich Änderungen melden lassen. In beiden Fällen zeichnen Sie den Statuscode und die Zeitstempel auf, die zusammen mit dem Wert zurückkommen.

Warum erhalte ich beim Verbinden BadCertificateUntrusted?

Weil der Client dem Zertifikat des Servers noch nicht vertraut. Die .NET-Bibliothek der OPC Foundation speichert abgelehnte Zertifikate im Speicher rejected. Prüfen Sie den Fingerabdruck des Zertifikats mit dem Administrator des Servers und verschieben Sie es dann in den Speicher trusted. Einstellungen, die Zertifikate automatisch akzeptieren, gehören nur in Entwicklungsumgebungen.

Welche Portnummer verwendet OPC UA?

Bei der IANA ist 4840/TCP als opcua-tcp registriert. Reale Server verwenden aber teils einen anderen Port, deshalb prüfen Sie die Einstellungen der Anlage. Läuft der Server unter Windows, muss die Verbindung zu diesem Port in der Windows-Firewall erlaubt werden, und liegt Netzwerktechnik dazwischen, auch auf diesen Geräten.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Vertretungsberechtigter von KomuraSoft LLC

Schwerpunkte sind Windows-Softwareentwicklung, technische Beratung und Fehleruntersuchung. Besondere Stärken liegen bei Projekten mit bestehenden Assets und bei der Untersuchung von Störungen, deren Ursache schwer erkennbar ist.