OPC UA koppelen aan Node-RED

Voordat u begint

• Een Node-RED-installatie met een ondersteunde Node.js-runtime, en toestemming om er palette nodes op te installeren. In een OT-netwerk is die toestemming vaak de echte blokkade.
• Een set OPC UA-clientnodes die u vanuit het palet installeert. Er bestaan meerdere concurrerende community-packages met verschillende nodenamen, verschillende configuratie en verschillende onderhoudsstatus; kies er één en wees consistent in al uw flows.
• Een werkende endpoint-URL en een duidelijke beslissing over security. Wilt u gesigneerd en versleuteld draaien, controleer dan of het door u gekozen node-package de policy ondersteunt die de server aanbiedt voordat u de flow bouwt.
• Ergens waar de data naartoe kan die niet Node-RED is. Het heeft zelf geen duurzame buffer.

Het opzetten

1. Installeer één OPC UA node-package en blijf daarbijInstalleer vanuit de palette manager en noteer daarna de naam en versie van het package in uw projectnotities. Twee OPC UA-packages mengen in één Node-RED-instance levert verwarrende dubbele nodetypes en conflicterende certificaatmappen op.
2. Bewijs het endpoint eerst met security NoneConfigureer de client-node met de endpoint-URL en zonder security, en lees één bekende node. Dit scheidt netwerk- en endpointproblemen van certificaatproblemen, en het kost een minuut.
3. Doe het certificaatwerk explicietZoek uit waar uw node-package het clientcertificaat en de trusted- en rejected-mappen op schijf bewaart en rond de uitwisseling in beide richtingen af: de server moet het Node-RED-clientcertificaat vertrouwen, en de client moet het servercertificaat vertrouwen. Dit is de stap die van een demo iets maakt dat een security review overleeft.
4. Adresseer nodes via de namespace-URI waar het pakket dat toelaatDe meeste community-nodes nemen een NodeId-string met een letterlijke namespace-index, vaak meegedragen in het bericht-topic. Als het pakket resolutie via namespace-URI ondersteunt, gebruik die dan. Zo niet, lees dan de NamespaceArray in een function node bij het starten van de flow en bouw de NodeId-strings daaruit op, in plaats van indexen in elke node te plakken.
5. Abonneer in plaats van te pollen, en begrens de rate vóór alles stroomafwaartsGebruik de subscription- of listener-node van het package met een publishing interval dat past bij wat de consumer nodig heeft. Zet vervolgens een rate limiter of een aggregatienode tussen de subscription en elke node die echt werk doet, want elk bericht draait op dezelfde event loop als de rest van uw flows.
6. Behandel herverbinden als een eersteklas gevalKoppel de statusuitgang van de client-node aan iets dat logt en alarmeert. Test door het endpoint op de firewall te blokkeren en te kijken of de flow vanzelf herstelt of een redeploy nodig heeft, want het antwoord verschilt per pakket en versie.
7. Breng de data onmiddellijk naar duurzame opslagStuur berichten rechtstreeks naar een MQTT-broker, een time-series database of een bestand, en houd transformaties na die hop. Node-RED herstart bij elke deploy, en alles wat op dat moment alleen in flow context staat, is weg.

Hoe de adresruimte eruitziet

Node-RED bouwt geen model. Elk bericht draagt één waarde, of een kleine batch, met wat het node-package ook heeft gekozen te tonen van de DataValue: meestal de waarde zelf, soms de StatusCode en de tijdstempels, en vaak niet de type-informatie. De structuur van de adresruimte is iets wat u per flow opnieuw ontdekt met een browse-node, en die wordt niet bewaard. Dat is acceptabel voor prototyping en voor lijmwerk, maar het betekent dat de semantiek van uw data in de flow-indeling en in nodenamen leeft, die niet doorzoekbaar zijn, niet standaard geversioneerd en niet overdraagbaar naar de volgende machine. Als dezelfde mapping twee keer gebruikt gaat worden, genereer de NodeId-lijst dan uit een browse en bewaar hem als bestand dat de flow inleest.

De valkuilen

• De community nodes zijn niet uniform in kwaliteit of onderhoud. Nodenamen, berichtformaten en indelingen van certificaatmappen verschillen tussen packages en tussen versies van hetzelfde package, dus leg vast tegen welk package en welke versie een flow gebouwd is.
• Een letterlijke namespace-index die in elke node is geplakt, is de standaardfaalwijze in Node-RED. Na een PLC-programmadownload geeft de hele flow in één keer BadNodeIdUnknown, en er is geen enkele plek om het te repareren.
• Certificaatafhandeling is het zwakste onderdeel van de meeste packages, en daarom draaien zoveel Node-RED-collectors in productie stilletjes met security None. Dat is een beslissing die iemand bewust moet nemen, geen standaard om te erven.
• Node-RED is single-threaded. Een subscription met een publishing interval van 50 ms op een paar honderd items laat de event loop verhongeren en maakt de editor zelf onresponsief, en het symptoom lijkt op een netwerkprobleem.
• Een deploy herstart flows, waardoor sessions en subscriptions wegvallen. Een kleine dashboardwijziging uitrollen onderbreekt dus de dataverzameling, en een Node-RED-instantie die verzamelt zou niet ook de instantie moeten zijn die mensen tijdens een ploeg bewerken.
• Er is geen store-and-forward. Is de downstream sink niet beschikbaar, dan zijn de berichten simpelweg verloren tenzij u zelf een buffer hebt gebouwd.
• Serverzijdige sessielimieten worden per client node verbruikt, en een flow met meerdere client nodes tegen één embedded PLC-server kan ze uitputten.

OEE-data eruit halen

Node-RED is een goede plek om te onderzoeken wat een machine beschikbaar stelt en een slechte plek om OEE te berekenen. Het kan een toestandsvariabele, een teller en een redencode uitlezen en doorsturen, wat echt nuttig is voor een proof of concept of voor een machine die op geen enkele andere manier bereikbaar is. Wat het u niet geeft, is de betrouwbaarheid die de berekening nodig heeft: geen duurzame buffer, verzameling die bij elke deploy onderbroken wordt, en timing die afhangt van een event loop die met al het andere in de instance wordt gedeeld. Gaat een Node-RED-collector naar productie, houd hem dan bij één taak, breng waarden onmiddellijk naar een broker of database met de servertimestamps intact, en bereken beschikbaarheid, prestatie en kwaliteit verderop in de keten, waar een gat zichtbaar en herverwerkbaar is. Geplande productietijd, ploegenkalenders en standaardcyclustijden zitten niet in de machine en horen niet hardcoded in een flow.

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.