OPC UA PubSub-Konnektor

Übersicht

Der OPC UA PubSub-Konnektor implementiert das Publish/Subscribe-Muster, das durch die OPC UA PubSub-Spezifikation (Teil 14) definiert ist. Er ermöglicht eine durchsatzstarke, entkoppelte Kommunikation zwischen OPC UA-Produzenten und -Konsumenten unter Verwendung eines von zwei Transport-Mappings:

• MQTT - JSON-codierte Nachrichten über MQTT/UDP für broker-basierte Verteilung
• UADP - Binäres UADP (UA Datagram Protocol) über UDP-Multicast für latenzarme LAN-Verteilung

Konnektor-Typen:

• OpcuaPubSubReader - Lauscht auf eingehende PubSub-Nachrichten und gibt sie als Meddle-Payloads aus
• OpcuaPubSubWriter - Veröffentlicht Meddle-Payloads als PubSub-Nachrichten

Funktionen

• ✅ Zwei Transports: MQTT (JSON) und UADP (Binär-Multicast)
• ✅ Automatische Dekodierung sowohl von JSON- als auch UADP-Wire-Formaten
• ✅ UDP-Multicast-Gruppenverwaltung mit Interface-Auswahl
• ✅ Optionale Filterung nach Publisher-ID und Dataset-Name
• ✅ Entkoppelter Producer/Consumer (keine Punkt-zu-Punkt-Sitzung erforderlich)
• ✅ Konzipiert für hochfrequente Telemetrie-Verteilung

Grundkonfiguration

OPC UA PubSub Reader

UADP (Multicast)

{
  "type": "OpcuaPubSubReader",
  "config": {
    "transport": "uadp",
    "multicastAddr": "opc.udp://224.0.5.1:4840/eth0",
    "publisherId": "Publisher_1",
    "dataSetName": "TankFarmDataSet"
  }
}

MQTT (JSON über UDP)

{
  "type": "OpcuaPubSubReader",
  "config": {
    "transport": "mqtt",
    "brokerUrl": "0.0.0.0:1883",
    "topic": "factory/line1",
    "publisherId": "Publisher_1",
    "dataSetName": "LineOneMetrics"
  }
}

OPC UA PubSub Writer

UADP (Multicast)

{
  "type": "OpcuaPubSubWriter",
  "config": {
    "transport": "uadp",
    "multicastAddr": "opc.udp://224.0.5.1:4840/eth0",
    "publisherId": "Publisher_1",
    "dataSetName": "TankFarmDataSet"
  }
}

MQTT (JSON über UDP)

{
  "type": "OpcuaPubSubWriter",
  "config": {
    "transport": "mqtt",
    "brokerUrl": "192.168.1.20:1883",
    "topic": "factory/line1",
    "publisherId": "Publisher_1",
    "dataSetName": "LineOneMetrics"
  }
}

Konfigurationsparameter

Transport

Der Wire-Transport, der für PubSub-Nachrichten verwendet wird. Muss einer der folgenden sein:

• mqtt - JSON-Nachrichten über UDP (in der Produktion broker-überbrückt)
• uadp - Binäre UADP-Frames über UDP-Multicast

{
  "transport": "uadp"
}

Broker URL (MQTT-Transport)

Erforderlich, wenn transport: mqtt. Die Adresse, an die Meddle bindet (Reader) oder an die gesendet wird (Writer).

{
  "brokerUrl": "192.168.1.20:1883"
}

Format: host:port.

Hinweise:

• Der Reader bindet einen UDP-Listener an diese Adresse
• Für den Writer ist dies die Zieladresse, an die PubSub-Nachrichten gesendet werden

Topic (MQTT-Transport)

Optionale logische Topic-Kennung. Informative Metadaten, die zusammen mit der Dataset-Filterung enthalten sind.

{
  "topic": "factory/line1"
}

Multicast-Adresse (UADP-Transport)

Erforderlich, wenn transport: uadp. Die IPv4-Multicast-Gruppe plus optionales Interface.

{
  "multicastAddr": "opc.udp://224.0.5.1:4840/eth0"
}

Format: opc.udp://<host>:<port>/<interface>.

• host:port - Die Multicast-Gruppe und der Port (typischerweise 224.0.5.1:4840 für den OPC UA PubSub-Standard)
• interface - Erforderlicher Netzwerkschnittstellenname (eth0, en0, lo0)

Warum ist das Interface erforderlich? UDP-Multicast-Joins sind interface-gebunden. Ohne ein angegebenes Interface kann das OS die Multicast-Gruppe nicht zuverlässig binden, insbesondere auf macOS (lo0) und Cloud-VMs mit mehreren NICs.

Reines host:port (ohne Schema) wird zur Abwärtskompatibilität ebenfalls akzeptiert, aber die Interface-Auswahl wird dringend empfohlen.

Publisher ID

Identifiziert die Quelle der PubSub-Nachrichten.

{
  "publisherId": "Publisher_1"
}

Hinweise:

• Erforderlich beim Writer (jede veröffentlichte Nachricht wird damit gekennzeichnet)
• Optional beim Reader (wenn gesetzt, werden nur Nachrichten von diesem Publisher behalten; wenn leer, werden alle Publisher akzeptiert)

DataSet Name

Identifiziert das logische Dataset innerhalb eines Publishers.

{
  "dataSetName": "TankFarmDataSet"
}

Hinweise:

• Optional sowohl beim Reader als auch beim Writer
• Beim Reader fungiert es als Filter, wenn gesetzt

Wire-Formate

JSON (MQTT-Transport)

Der MQTT-Transport gibt Nachrichten in einem standardmäßigen JSON-Umschlag aus:

{
  "PublisherId": "Publisher_1",
  "Messages": [
    {
      "DataSetName": "TankFarmDataSet",
      "Payload": {
        "tank_1_level": 78.4,
        "tank_2_level": 62.1,
        "pump_running": true
      }
    }
  ]
}

UADP (UADP-Transport)

Der UADP-Transport gibt binäre Frames gemäß OPC UA Teil 14-Framing aus. Der Reader erkennt automatisch UADP vs. JSON-Inhalt und dekodiert beide. Jedes dekodierte UADP-DataSet gibt eine Meddle-Payload aus.

Datenfluss

Reader

Multicast / UDP → OpcuaPubSubReader → (JSON oder UADP dekodieren) → Meddle-Payload(s)

Mehrere Datasets in einer einzelnen Netzwerknachricht produzieren mehrere Meddle-Payloads (eine pro Dataset).

Writer

Meddle-Payload → OpcuaPubSubWriter → (JSON-Umschlag codieren) → UDP-Sendung → Subscribers

Der Writer gibt für beide Transports immer JSON aus. Jeder Write-Aufruf produziert genau eine Netzwerknachricht.

Häufige Anwendungsfälle

1. Entkoppelte Anlagen-Telemetrie-Verteilung

Eine zentrale SPS veröffentlicht Prozessvariablen an eine UADP-Multicast-Gruppe; mehrere Meddle-Subscriber konsumieren sie unabhängig.

{
  "type": "OpcuaPubSubReader",
  "config": {
    "transport": "uadp",
    "multicastAddr": "opc.udp://224.0.5.1:4840/eth0",
    "publisherId": "PLC_Master"
  }
}

2. MQTT-überbrückte IoT-Telemetrie

OPC UA PubSub zu einem JSON-freundlichen MQTT-Topic für die Aufnahme in Cloud-Plattformen überbrücken:

{
  "type": "OpcuaPubSubReader",
  "config": {
    "transport": "mqtt",
    "brokerUrl": "0.0.0.0:1883",
    "topic": "factory/sensors",
    "dataSetName": "EnergyMeters"
  }
}

3. Edge-Gateway, das aggregierte KPIs veröffentlicht

Nach der Verarbeitung aggregierte KPIs als einzelne PubSub-Nachricht veröffentlichen:

{
  "type": "OpcuaPubSubWriter",
  "config": {
    "transport": "uadp",
    "multicastAddr": "opc.udp://224.0.5.1:4840/eth0",
    "publisherId": "Edge_Gateway_1",
    "dataSetName": "PlantKPIs"
  }
}

Fehlerbehebung

Keine Nachrichten empfangen (UADP)

Problem: Reader läuft still, gibt aber niemals Payloads aus

Lösungen:

1. Bestätigen, dass die Multicast-Gruppe exakt mit dem Publisher übereinstimmt (224.0.5.1:4840)
2. Das Interface in multicastAddr angeben (z.B. /eth0) — automatische Erkennung ist nicht zuverlässig
3. Einen Netzwerk-Sniffer wie tcpdump -i eth0 host 224.0.5.1 and port 4840 verwenden, um zu bestätigen, dass Pakete ankommen
4. Überprüfen, ob Multicast-Routing auf Switches/Routern zwischen Publisher und Subscriber aktiviert ist

network interface is required

Problem: UADP-Konfiguration wird beim Start abgelehnt

Lösungen:

1. multicastAddr aktualisieren, um das Interface einzuschließen: opc.udp://224.0.5.1:4840/eth0
2. Auf macOS ist das Loopback-Interface lo0; auf Linux ist es lo. Mit ifconfig oder ip addr prüfen

Publisher herausgefiltert

Problem: Reader sieht Nachrichten auf der Leitung, gibt aber keine aus

Lösungen:

1. Den publisherId-Filter am Reader prüfen — wenn gesetzt, passieren nur Nachrichten von diesem Publisher. Löschen Sie ihn, um alle zu akzeptieren
2. Dasselbe gilt für dataSetName — wenn gesetzt, passieren nur übereinstimmende Datasets

UDP-Port bereits in Verwendung

Problem: bind: address already in use

Lösungen:

1. Mehrere Reader auf demselben Host müssen unterschiedliche Ports verwenden
2. Für UADP-Multicast können mehrere Prozesse auf demselben Host nur dann derselben Gruppe beitreten, wenn SO_REUSEPORT honoriert wird (Linux); unter macOS ist nur eine Bindung pro Gruppe+Port pro Prozess erlaubt

Dekodierungsfehler

Problem: ErrOpcuaPubSubDecode wird bei jeder Nachricht ausgelöst

Lösungen:

1. Prüfen, ob der Publisher JSON oder UADP verwendet — der Reader erkennt automatisch, aber fehlerhafte Daten lassen beide Pfade scheitern
2. Die PubSub-Konfiguration des Publishers überprüfen: Dataset-Inhaltstyp muss ein unterstützter Skalar oder eine unterstützte Struktur sein
3. Überprüfen, dass Publisher und Subscriber sich auf die Codierung einigen (die PubSub-Konfiguration des OPC UA-Servers definiert dies)

Best Practices

1. UADP für die In-Plant-Verteilung verwenden

UADP ist schneller und hat weniger Overhead als JSON über MQTT. Verwenden Sie es immer dann, wenn Sie das Netzwerk kontrollieren.

2. MQTT-JSON für Site-übergreifende Bridges verwenden

JSON ist portabel und einfach zu debuggen. Wenn Nachrichten das öffentliche Internet durchqueren oder von Nicht-OPC UA-Tools konsumiert werden müssen, ist MQTT-JSON pragmatischer.

3. Immer das Interface auf UADP setzen

Verlassen Sie sich niemals darauf, dass das OS die richtige NIC “errät”. Multi-Homed-Hosts und Container scheitern ansonsten still.

4. Beim Subscriber filtern

publisherId- und dataSetName-Filterung ist serverseitig kostengünstig und reduziert die nachgelagerte Verarbeitungslast drastisch.

5. IP-Multicast sorgfältig planen

• Den reservierten Bereich der OPC UA Foundation verwenden (224.0.5.0/24)
• Mit Ihrem Netzwerkteam koordinieren — unkontrollierter Multicast kann das LAN überfluten
• Vor der Produktion mit tcpdump/Wireshark testen

Beispiel-Workflows

Anlagenweite Telemetrie-Verteilung

SPS (Publisher) → UADP-Multicast 224.0.5.1:4840
                                     │
                            ┌────────┼────────┬──────────────┐
                            ↓        ↓        ↓              ↓
                     OpcuaPubSubReader   OpcuaPubSubReader   OpcuaPubSubReader
                      (Speicher)         (Dashboard)         (Alarmierung)
                            │                 │                  │
                            ↓                 ↓                  ↓
                    InfluxDb2Writer        Chart              Isa182 → Alert

Edge-zu-Cloud-Bridge

ModbusReader → Reshape → OpcuaPubSubWriter (MQTT) → Externer Broker → Cloud-Subscriber

Überbrückt Legacy-Modbus-Geräte in das moderne OPC UA PubSub-Ökosystem.

Verwandte Konnektoren

• OPC UA - Klassisches OPC UA-Client/Server-Protokoll (Punkt-zu-Punkt)
• MQTT v5 - Generisches MQTT (nicht-OPC UA) PubSub
• Modbus - Legacy-Geräte in das PubSub-Gewebe überbrücken
• Reshape - Feldnamen vor dem Veröffentlichen normalisieren
• InfluxDB - Abonnierte Telemetrie persistieren

Zusätzliche Ressourcen

• OPC UA Teil 14: PubSub - Offizielle Spezifikation
• OPC Foundation
• UADP-Netzwerknachrichten-Referenz
• IANA-Multicast-Adressen
• Wireshark OPC UA PubSub Dissector