OPC UA PubSub

Wat is OPC UA PubSub?

OPC UA PubSub is het deel van de OPC UA-standaard (Part 14, OPC 10000-14) dat het publish/subscribe-patroon toepast, waarbij publishers data versturen zonder te weten wie die ontvangt en subscribers alleen de berichten verwerken waarin ze geïnteresseerd zijn. De afkorting PubSub staat voor publish/subscribe: een algemeen communicatiepatroon dat ook de basis vormt van MQTT en DDS. OPC UA PubSub combineert dat patroon met het informatiemodel en de beveiliging van OPC UA, en verstuurt de berichten via UDP multicast, rechtstreeks over Ethernet of via een broker zoals MQTT of AMQP. De eerste versie verscheen in februari 2018 als onderdeel van OPC UA 1.04; de huidige versie hoort bij OPC UA 1.05.

🧠 Wat is het publish/subscribe-patroon?

Bij het klassieke client/server-model vraagt een client steeds opnieuw om data: de SCADA-server leest elke seconde registers uit een PLC (polling), zoals bij Modbus TCP gebruikelijk is. Bij publish/subscribe draait die relatie om. De bron publiceert zelf, en de afnemers abonneren zich. Zender en ontvanger zijn daardoor op drie manieren ontkoppeld:

• In ruimte - de publisher kent de subscribers niet en hoeft geen verbinding per afnemer bij te houden
• In tijd - bij een broker hoeven zender en ontvanger niet tegelijk actief te zijn
• In aantal - een extra afnemer kost de publisher geen extra werk

Het patroon kent twee hoofdvormen:

• Met broker - een centrale tussenpersoon ontvangt alle berichten en verdeelt ze per topic. MQTT is hiervan het bekendste voorbeeld in OT; ook Apache Kafka en AMQP werken zo.
• Zonder broker - publishers sturen berichten rechtstreeks het netwerk op, meestal via multicast. DDS (Data Distribution Service) van de Object Management Group werkt zo: deelnemers vinden elkaar via automatische discovery en wisselen data uit via het RTPS-protocol, met ruim twintig instelbare QoS-policies voor onder meer betrouwbaarheid en historie. DDS is onder andere de middleware onder ROS 2 in de robotica.

OPC UA PubSub ondersteunt beide vormen. Dat maakt het bijzonder: hetzelfde informatiemodel werkt zowel voor snelle machine-naar-machinecommunicatie als voor koppeling met de cloud.

🔧 Hoe werkt OPC UA PubSub?

Part 14 scheidt wat er wordt verstuurd (het berichtformaat) van hoe het wordt verstuurd (het transport).

De configuratie is hiërarchisch opgebouwd:

1. PublishedDataSet - welke variabelen of events worden gepubliceerd
2. DataSetWriter - maakt van een dataset een DataSetMessage
3. WriterGroup - bundelt de berichten van meerdere writers in één NetworkMessage, met een vast publicatie-interval
4. PubSubConnection - koppelt alles aan een transportadres en een unieke PublisherId
5. ReaderGroup en DataSetReader - aan de kant van de subscriber, die berichten filtert en decodeert

Om bandbreedte te sparen kent PubSub key frames en delta frames. Een key frame bevat alle velden van een dataset; een delta frame alleen de velden die zijn veranderd. Met de parameter KeyFrameCount bepaalt u hoe vaak een volledig bericht wordt gestuurd. Subscribers die de structuur van de data nog niet kennen, krijgen die via DataSetMetaData-berichten.

🔄 Wat is het verschil tussen OPC UA client/server en PubSub?

PubSub vervangt client/server niet. In de praktijk gebruikt u client/server om een apparaat te configureren en de adresruimte te verkennen, en PubSub om de procesdata efficiënt te verspreiden.

🔄 Hoe verhoudt OPC UA PubSub zich tot MQTT en DDS?

MQTT transporteert alleen bytes; de betekenis van de data ligt niet vast. Daarom zijn afspraken als MQTT Sparkplug B ontstaan. OPC UA PubSub over MQTT levert wel een vastgelegd formaat met metadata en verwijzingen naar het OPC UA-informatiemodel. DDS is net als OPC UA PubSub brokerloos inzetbaar, maar komt uit de defensie-, robotica- en simulatiewereld en heeft een eigen datamodel. In fabrieken zijn OPC UA en MQTT veel gangbaarder; DDS komt u vooral tegen bij robots en autonome systemen.

🏭 Waar wordt OPC UA PubSub gebruikt?

• Controller-naar-controller - PLC’s van verschillende merken wisselen cyclisch data uit via UDP multicast; dit is de basis van OPC UA FX
• Deterministische netwerken - over TSN krijgt PubSub begrensde latentie en weinig jitter, nodig voor realtime besturing
• Edge naar cloud - een edge-gateway publiceert machinedata als JSON via MQTT naar een cloudplatform, MES of historian
• Unified Namespace - PubSub over MQTT kan een UNS voeden naast of in plaats van Sparkplug B
• Alarm- en eventdistributie - events naar meerdere afnemers zonder dat elk systeem apart moet pollen

🔐 Hoe beveiligt u OPC UA PubSub?

Omdat er geen sessie is tussen publisher en subscriber, werkt de beveiliging anders dan bij client/server. Alle deelnemers van een SecurityGroup delen symmetrische sleutels, die een Security Key Service (SKS) uitdeelt. In het pull-model halen deelnemers de sleutels zelf op via een beveiligde OPC UA-verbinding; in het push-model zet de SKS ze bij de deelnemers neer. Sleutels hebben een beperkte levensduur (KeyLifetime) en worden regelmatig vervangen.

Deze berichtbeveiliging met groepssleutels is in Part 14 gedefinieerd voor de binaire UADP-codering. JSON-berichten over MQTT hebben geen eigen ondertekening of versleuteling en zijn afhankelijk van TLS tussen deelnemer en broker en van de beveiliging van de broker zelf. Omdat u de broker dan moet vertrouwen, is end-to-endbeveiliging van publisher tot subscriber alleen mogelijk met UADP.

Aandachtspunten in de praktijk:

• Zet SignAndEncrypt aan - met SecurityMode None is elk bericht te lezen en na te maken, wat spoofing en een replay-aanval mogelijk maakt
• Beveilig de SKS - wie de SKS bereikt, kan de sleutels van een hele groep krijgen
• Segmenteer multicastverkeer - houd het binnen een eigen VLAN en zone volgens netwerksegmentatie en IEC 62443; multicast hoort niet over een firewall naar kantoor
• Brokervarianten - gebruik TLS, authenticatie per client en rechten per topic op de broker
• Certificaten - de SKS en clients gebruiken X.509-certificaten; regel het beheer ervan met certificaatbeheer
• Monitoring - stuur logs van broker en SKS naar een SIEM en let op onbekende PublisherIds of afwijkende berichtfrequenties

🛠️ Hoe zet u OPC UA PubSub in de praktijk op?

1. Kies het transport per stroom - UDP of Ethernet voor snelle data binnen een cel, MQTT voor stromen naar IT en cloud
2. Kies de codering - UADP voor cycli van milliseconden, JSON wanneer IT-systemen de data direct moeten lezen
3. Ontwerp de datasets - groepeer variabelen met hetzelfde interval in één WriterGroup en houd een UDP-bericht binnen één MTU (maximaal 1.472 bytes payload bij IPv4) om fragmentatie te voorkomen
4. Regel multicast in het netwerk - subscribers melden zich aan via IGMP; zorg dat switches IGMP-snooping ondersteunen, anders overspoelt multicast het netwerk
5. Richt beveiliging in - SKS, SecurityGroups, sleutellevensduur en certificaten
6. Test met meerdere leveranciers - controleer welke profielen een apparaat ondersteunt, want niet elk product kent alle transporten en coderingen

❓ Veelgestelde vragen

Wat betekent PubSub?

PubSub is de afkorting van publish/subscribe, een communicatiepatroon waarin zenders berichten publiceren zonder de ontvangers te kennen. Ontvangers abonneren zich op de data die ze nodig hebben. MQTT, DDS en OPC UA PubSub zijn bekende toepassingen van dit patroon in de industrie.

Heeft OPC UA PubSub een broker nodig?

Nee, OPC UA PubSub werkt zowel met als zonder broker. Zonder broker gaan berichten via UDP multicast of rechtstreeks over Ethernet, wat geschikt is voor snelle communicatie binnen een machine of cel. Met broker gebruikt OPC UA PubSub MQTT of AMQP, wat handig is voor koppelingen met IT en cloud.

Is OPC UA PubSub hetzelfde als MQTT?

Nee, MQTT is een transportprotocol met een verplichte broker, terwijl OPC UA PubSub een specificatie is die MQTT als een van de transporten kan gebruiken. OPC UA PubSub voegt daar een vast berichtformaat, metadata en de koppeling met het OPC UA-informatiemodel aan toe. Beide vullen elkaar dus aan.

Is OPC UA PubSub geschikt voor realtime besturing?

OPC UA PubSub met UADP-codering over UDP of Ethernet is compact genoeg voor snelle cyclische communicatie. Voor gegarandeerde latentie combineert u het met TSN, zoals OPC UA FX doet. Over een broker als MQTT is OPC UA PubSub niet bedoeld voor harde realtime regelingen.

Hoe wordt OPC UA PubSub beveiligd?

OPC UA PubSub beveiligt berichten met groepssleutels die een Security Key Service uitdeelt, met de modi None, Sign en SignAndEncrypt; die berichtbeveiliging is gedefinieerd voor UADP. JSON-berichten via een broker zijn afhankelijk van TLS en toegangsrechten op de broker. Netwerksegmentatie blijft daarnaast nodig, vooral voor multicastverkeer.

Wat is het verschil tussen OPC UA PubSub en OPC UA FX?

OPC UA PubSub beschrijft hoe berichten worden gepubliceerd en ontvangen. OPC UA FX bouwt daarop voort met informatiemodellen, verbindingsbeheer en profielen, zodat controllers en veldapparaten van verschillende leveranciers echt samenwerken. PubSub is dus het transportmechanisme, OPC UA FX de afspraak over wat er wordt uitgewisseld.

📌 Samengevat

OPC UA PubSub brengt het publish/subscribe-patroon naar OPC UA. Publishers sturen data zonder de afnemers te kennen, via UDP multicast, Ethernet of een broker zoals MQTT. Met UADP en TSN is het geschikt voor snelle veldcommunicatie, met JSON en MQTT voor de koppeling met IT en cloud. Beveiliging verloopt via groepssleutels uit een Security Key Service (UADP) of via TLS op de broker (JSON), en vraagt om goede segmentatie.

OPC UA PubSub combineert de schaalbaarheid van publish/subscribe met het informatiemodel en de beveiliging van OPC UA, van de veldlaag tot de cloud.