ℹ️ Enterprise-Funktion. Verfügbar ab QuickHMI 14.15.2.
Bei der Datenbereitstellung über OPC UA PubSub sendet QuickHMI die freigegebenen Variablen zyklisch als PubSub-Nachrichten, wahlweise direkt über UDP oder über einen MQTT-Broker. Anders als bei den beiden übrigen Wegen verbindet sich dabei niemand mit QuickHMI: Es gibt keine Sitzung und keine Anfrage, QuickHMI sendet im eingestellten Intervall, ob jemand zuhört oder nicht. Jeder Wert wird mit seiner Qualität und seinem Zeitstempel übertragen.
Abgrenzung
- Gegenüber der OPC-UA-PubSub-Datenquelle: Dort empfängt QuickHMI PubSub-Nachrichten eines fremden Publishers. Hier ist QuickHMI selbst der Publisher.
- Gegenüber der Datenbereitstellung über MQTT: Dort ist QuickHMI selbst der Broker, und die Clients abonnieren einzelne Topics je Variable. Bei PubSub über einen Broker ist QuickHMI nur ein Client dieses Brokers und veröffentlicht eine geschlossene Datenmenge (DataSet) in OPC-UA-Kodierung.
Aktivierung
Den Weg aktivieren Sie in den Projekt-Einstellungen im Bereich Datenbereitstellung im Reiter OPC UA PubSub. Welche Variablen gesendet werden, legen Sie in derselben Ansicht als Regel je Datenquelle und als Ausnahme je Variable fest; das Vorgehen ist für alle Wege gleich und im Überblick beschrieben.

Ziel und Transport
Unter Endpoint geben Sie an, wohin gesendet wird:
opc.udp://<Host>:<Port>für direktes UDP. Je nach Adresse ist das Unicast (eine bestimmte Gegenstelle), Multicast (eine Gruppenadresse) oder Broadcast.mqtt://,mqtts://,ws://oderwss://gefolgt von Host und Port, wenn die Nachrichten über einen MQTT-Broker laufen sollen.
Beim Weg über einen Broker legen Sie zusätzlich fest:
- MQTT-Payload: das Nachrichtenformat auf dem Broker, JSON (interoperabel, gut lesbar) oder UADP (binär und kompakter).
- MQTT-Daten-Topic: das Topic, auf dem die Werte bereitgestellt werden. Bleibt das Feld leer, wird die aus dem DataSet-Namen abgeleitete Vorgabe verwendet.
UDP kennt kein Retain. Ein Empfänger, der sich später einschaltet, sieht erst dann wieder alle Werte, wenn die nächste vollständige Nachricht gesendet wird. Über die KeyFrame-Anzahl steuern Sie, wie oft das geschieht. Über einen MQTT-Broker steht der zuletzt gesendete Stand dagegen als retained Nachricht bereit.
Kennungen
PubSub-Empfänger filtern die Nachrichten anhand fester Kennungen. Diese Angaben müssen deshalb mit der Einstellung der Gegenstelle übereinstimmen, sonst verwirft sie die Nachrichten:
- Publisher-ID und der zugehörige Typ (String für Text-Kennungen, Byte, UInt16, UInt32 oder UInt64 für numerische): die Kennung des sendenden Publishers, also von QuickHMI. Pflichtangabe.
- DataSet-Name: Name der veröffentlichten Datenmenge. Empfänger sprechen die Daten über diesen Namen an.
- Writer-Gruppen-ID: Kennung der Writer-Gruppe.
- DataSetWriter-ID: Kennung dieses Writers innerhalb der Gruppe. Empfänger filtern damit einzelne Datenmengen heraus.
Welchen Feldnamen eine einzelne Variable im DataSet belegt, zeigt der Variablen-Dialog als OPC-PubSub-Feldname. Abonnenten sprechen die Variable über diesen Namen an.
Sendeintervall und KeyFrames
- Sendeintervall (ms): Wie oft die Werte gesendet werden. Da PubSub zyklisch sendet, bestimmt dieses Intervall, wie aktuell die bereitgestellten Werte sind.
- KeyFrame-Anzahl: Jede n-te Nachricht enthält alle Werte statt nur der geänderten. Empfänger benötigen diese vollständigen Nachrichten zum Einstieg und zur Neusynchronisierung nach einem Nachrichtenverlust. Ein kleinerer Wert bedeutet schnellere Erholung, ein größerer Wert weniger Datenlast.
Sicherheit
- UADP-Modus: signiert oder verschlüsselt die gesendeten Nachrichten. Beim Weg über einen MQTT-Broker setzt das das Nutzlastformat UADP voraus, mit JSON ist es nicht möglich.
- UADP-Schlüsselquelle: None für unverschlüsselten Versand oder Preshared für einen fest vereinbarten Schlüssel. Diesen hinterlegen Sie als Preshared-Key (Base64) zusammen mit der Security-Token-ID. Beides muss auf beiden Seiten identisch sein.
- Authentifizierung am Broker: keine, Benutzername und Passwort oder ein Client-Zertifikat (nur bei MQTT). Bei
mqttsundwssist QuickHMI der Client des fremden Brokers: Dem Zertifikat des Brokers muss vertraut werden, sonst kommt die Verbindung nicht zustande. Ein noch nicht vertrautes Zertifikat erscheint im Zertifikatsmanager unter Abgelehnt und lässt sich dort freigeben. Ein eigenes Client-Zertifikat für die Zertifikatsanmeldung stammt ebenfalls von dort.
Kommando-Kanal (optional)
Die Datenbereitstellung sendet Werte ausschließlich nach außen. Sollen andere Systeme auch schreiben können, übernimmt das der Kommando-Kanal: Er nimmt Kommandos entgegen und schreibt sie in Variablen, die für PubSub auf ReadWrite stehen. Einen eigenen Schalter gibt es dafür nicht, der Kanal ergibt sich aus der Zugriffsebene der Variablen.
Wichtig: Die Angaben der Gruppe Kommando beschreiben die Gegenstelle, deren Kommandos angenommen werden, nicht die eigene Sende-Identität. Sobald mindestens eine Variable auf ReadWrite steht, ist die Publisher-ID der Gegenstelle deshalb eine Pflichtangabe. Ein leeres Feld bedeutet nicht „Kommandos beliebiger Gegenstellen annehmen“, sondern der Kanal könnte gar nichts empfangen. Der Editor weist beim Speichern darauf hin.
- Endpoint: Ziel-Endpoint für die Kommandos. Leer bedeutet: derselbe wie für die Werte.
- DataSet-Name: Name des DataSets, das QuickHMI als Kommando publiziert.
- Publisher-ID (mit Typ): Kennung der Gegenstelle, deren Kommandos angenommen werden. Pflichtangabe, sobald eine Variable auf ReadWrite steht.
- DataSetWriter-ID: DataSetWriter-ID der Gegenstelle. Leer bedeutet: beliebiger Writer.
- MQTT-Daten-Topic: Basis-Topic des Kommando-Kanals beim Weg über einen Broker.
Betrieb prüfen
Ob der Weg läuft, zeigt das Register Laufzeit der Projekt-Einstellungen. Ein Weg ohne freigegebene Variablen wird gar nicht erst gestartet. Schlägt der Start fehl, nennt die Meldung die Ursache.
Lizenz
Die Datenbereitstellung setzt eine Enterprise-Lizenz voraus. Davon zu unterscheiden ist die OPC-UA-PubSub-Datenquelle, mit der QuickHMI fremde PubSub-Nachrichten empfängt; sie setzt eine Ultimate-Lizenz voraus.
