OPC UA koppelen aan Mosquitto / MQTT-broker

Voordat u begint

• Iets dat daadwerkelijk OPC UA spreekt: een publisher, een collector of een gateway. De broker is een bestemming, geen client, en geen enkele brokerconfiguratie laat een PLC publiceren.
• Een beslissing over payloadformaat voordat het eerste topic bestaat. OPC UA PubSub over MQTT met JSON is de op standaarden gebaseerde route; de eigen JSON-vorm van een collector en Sparkplug B zijn de gangbare alternatieven, en ze zijn niet uitwisselbaar.
• Een topicnaamconventie die afgestemd is met degene die hem gaat afnemen, want de topicboom is het contract en hem later hernoemen breekt elke subscriber in één keer.
• TLS met echte certificaten en authenticatie geconfigureerd voordat er iets productiefs publiceert. Een open broker op een fabrieksnetwerk is een open fabriek.

Het opzetten

1. Configureer eerst de broker voor TLS en authenticatieStel een expliciete listener in, schakel anonieme toegang uit, configureer inloggegevens of clientcertificaten en voeg per client topic-toegangscontrole toe. Dit doen voordat er ook maar één publisher bestaat, is veel eenvoudiger dan het later over een vloot publishers heen alsnog aanbrengen.
2. Ontwerp de topichiërarchie vanuit de fabriek, niet vanuit de adresruimteEen topicboom die mechanisch is afgeleid van OPC UA-browsepaden is handig en levert topics op waar niemand zinvol op kan abonneren. Leid hem af van site, area, lijn en machine, en zet de signaalnaam op het blad. Waar een publisher wel automatische routing vanuit browsenamen biedt, moet u weten dat gereserveerde MQTT-tekens ge-escaped moeten worden, en controleren wat de publisher ermee doet.
3. Kies de payload-encoding en leg die vastAls u OPC UA PubSub over MQTT gebruikt, kies dan tussen UADP en JSON, en bij JSON tussen de reversible en de non-reversible vorm. Non-reversible JSON verliest type-informatie en kan niet worden teruggezet, en dat is een verrassing die maanden later bij een afnemer stroomafwaarts opduikt.
4. Bepaal retained messages en last will per topicklasseRetained messages geven een nieuwe subscriber direct de huidige waarde, wat juist is voor toestand en identiteit en onjuist voor events, waar een retained message iets herhaalt dat al is gebeurd. Configureer een last-will-topic per publisher zodat een uitgevallen collector zichtbaar is.
5. Stem quality of service af op de betekenis van de dataQuality of service 0 is prima voor een hoogfrequente analoge waarde die u toch opnieuw bemonstert en onacceptabel voor een stilstandsgebeurtenis of een tellerophoging, want een netwerkhapering laat die simpelweg verdwijnen. Gebruik at-least-once voor alles waarvan een berekening afhangt en maak consumers idempotent.
6. Verifieer de payload met een client voordat u consumenten bouwtAbonneer u met MQTT Explorer of een commandoregelclient en lees de werkelijke bytes op de lijn. Let er in het bijzonder op dat in de OPC UA JSON-codering een Good-status de nulwaarde is en wordt weggelaten, zodat een ontbrekend statusveld goed betekent en niet ontbrekende data.
7. Bewaak de broker en de publishers afzonderlijkHoud het aantal brokerverbindingen en verworpen berichten in de gaten, en alarmeer op de liveness van publishers via last-will-topics of een heartbeat-topic per machine. Stilte op een topic is dubbelzinnig en heeft een onafhankelijk signaal nodig om te duiden.

Hoe de adresruimte eruitziet

MQTT heeft geen model, alleen een topicstring en een payload, dus alles wat de OPC UA-adresruimte wist, moet opnieuw worden uitgedrukt door wat er publiceert. Dat is de centrale ontwerpbeslissing van een unified namespace: de topichiërarchie plus het payloadschema is het hele informatiemodel voor elke consument. OPC UA PubSub draagt dataset-metadata naast de data mee, wat typen en veldnamen behoudt en de reden is waarom het op standaarden gebaseerde pad de extra configuratie waard is; de JSON van een ad-hoc collector doet dat meestal niet, en dan staat de betekenis van een veld ergens in een document. Wat u ook kiest, publiceer de OPC UA-namespace-URI en node-identifier in de payload of in de topic-metadata, zodat een waarde te herleiden is tot de node waar die vandaan kwam.

De valkuilen

• De broker als de integratie beschouwen is de klassieke fout. De broker verplaatst bytes; de semantiek komt uit het topic- en payloadontwerp van de publisher, en in dat ontwerp zit het echte werk van het project.
• Quality of service 0 op eventachtige data verliest stilzwijgend events, juist onder de netwerkomstandigheden die de interessantste events opleveren. Stilstandsrecords en tellerophogingen hebben at-least-once-aflevering nodig.
• Retained messages op event-topics spelen verouderde events af naar elke nieuwe subscriber, wat afnemers corrumpeert die aannemen dat een bericht nu betekent.
• Niet-omkeerbare JSON-codering verliest type-informatie en kan niet heen en terug worden vertaald. Kies bewust en leg de keuze vast; dit stroomafwaarts ontdekken is duur.
• In de OPC UA JSON-encoding is een Good-status nul en wordt die weggelaten, dus een afnemer die een ontbrekend statusveld als ontbrekende data behandelt, gooit goede waarden weg.
• Topicbomen die automatisch uit browse paths worden afgeleid, coderen de interne structuur van de PLC in uw fabrieksbrede namespace, en ze veranderen wanneer het PLC-programma verandert.
• De broker wordt een fabrieksbreed single point of failure en een fabrieksbrede securitygrens. Cluster hem of accepteer het risico expliciet, en laat anonieme toegang nooit aan staan omdat het tijdens de inbedrijfstelling handig was.
• MQTT geeft geen garantie op volgorde over verschillende topics heen. Een toestandswijziging en de telling die erbij hoort kunnen in de verkeerde volgorde aankomen als ze op afzonderlijke topics worden gepubliceerd, dus zet feiten die consistent moeten zijn in één bericht.

OEE-data eruit halen

De broker draagt op zichzelf niets bij aan OEE en kan die ongemerkt beschadigen. Wat hij goed doet, is verzameling loskoppelen van berekening, zodat een analyseplatform machinetoestand, aantallen en redenen kan afnemen zonder tegen elke PLC sessies open te houden. De eisen die hij oplegt zijn concreet: publiceer toestandsovergangen als events met de eigen timestamp van de machine in de payload in plaats van te vertrouwen op aankomsttijd, publiceer tellerophogingen of absolute tellers met genoeg context om resets te herkennen, gebruik voor beide at-least-once delivery, en geef elke machine een heartbeat- of last-will-topic zodat stilte te onderscheiden is van een gestopte machine. Geplande productietijd, ploegenkalenders, ordercontext en standaardcyclustijden zijn geen machinedata en horen vanuit MES of ERP bij de berekening te komen, niet door met de hand op een topic gepubliceerd en vervolgens vergeten te worden.

Laatst geverifieerd op 7 september 2026 tegen OPC UA 1.05.07. OPC UA Connect is een educatieve bron en is niet gelieerd aan de OPC Foundation.