Platformonafhankelijke gegevensuitwisseling: OPC UA – een overzicht

Vanaf een bepaald niveau van complexiteit is specialisatie de snelste manier om een taak uit te voeren. De oprichting van OPC (Open Platform Communications) in 1996 volgde precies uit dit inzicht. Een ontwikkelingsteam van de vijf bedrijven Rockwell, Opto 22, Fisher-Rosemount, Intellution en Intuitive Technologies ontwikkelde een fabrikantonafhankelijk communicatieschema onder de naam OLE for Process Control.

Hun doel was een interface te creëren waarmee PLC's zowel live- als historische informatie konden leveren en alarmen konden activeren. Na verloop van tijd bleek de sterke afhankelijkheid van Microsoft OLE (Object Linking and Embedding) een beperking die het gebruik van de standaard buiten het Windows-platform onnodig bemoeilijkte.

Om dit probleem op te lossen werd een nieuwe variant van het protocol geïntroduceerd, gebaseerd op het destijds relevante ontwerpprincipe van service-oriented architecture, met een scheiding tussen de gegevens en de diensten die deze gegevens leveren.

Wie heeft voordeel van OPC UA, en wat kost het?

Voordat we de technische details bespreken, is het de moeite waard om de rol van OPC UA (Unified Architecture) binnen verbonden systemen als geheel te bekijken. In principe is OPC UA een abstractielaag die de koppeling van automatiseringscomponenten van verschillende fabrikanten mogelijk maakt. Voor ontwikkelaars is het systeem op twee manieren relevant. Ten eerste als programmeerinterface voor interactie met kant-en-klare automatiseringscomponenten. Ten tweede kan OPC UA interessant zijn voor zelfontwikkelde automatiseringscomponenten, iedereen die deze technologie ondersteunt, zal zeker profiteren van een brede marktacceptatie.

De volgende vraag betreft de kosten. Echte OPC UA-systemen bestaan bijna altijd uit twee componenten, enerzijds de specificaties die door de OPC Foundation worden geleverd en anderzijds de daadwerkelijke code. Over het algemeen zijn de specificaties beschikbaar onder verschillende opensourcelicenties, waardoor er geen kosten ontstaan voor het gebruik ervan. Iedereen die echter voorbeeldcode van de Foundation wil gebruiken die de specificatie implementeert, moet lid worden van de Foundation. Meer informatie is te vinden op. Voor kleine bedrijven kan een jaarlijks lidmaatschap minder dan €1.000 kosten.

De tweede grote kostenfactor is de code die als basis voor de implementatie wordt gebruikt. Door de enorme omvang is het onrealistisch voor een klein bedrijf om zelf een OPC UA-stack te ontwikkelen, wat betekent dat de leverancier van de stack een vergoeding voor zijn werk zal verwachten. De prijs hangt af van onderhandelingsvaardigheden, het doelplatform en de bestelhoeveelheid. Daarnaast zijn er proef- en demoversies van de verschillende stacks beschikbaar, evenals opensource-implementaties van een OPC-UA-server en meer (zie hieronder).

Systeem voor verschillende technologieën

Door de ervaringen die zijn opgedaan met het gebruik van OLE in de eerste versie van OPC, is OPC UA ontworpen om zo technologie-onafhankelijk mogelijk te zijn. Daardoor kunnen verschillende standaardprotocollen worden gebruikt, afhankelijk van de taak. Hier volgt een kort overzicht van veelgebruikte technologieën:

De basisbouwsteen van elke OPC UA-gebaseerde architectuur is het Uniform OPC UA Object, dat, schematisch en niet-wetenschappelijk weergegeven, eruitziet zoals geïllustreerd in Figuur 1.
 

Een OPC UA-object kan eigenschappen en procesgegevens beschikbaar stellen via zijn variables, waaronder niet alleen actuele informatie, maar ook expliciet historische informatie. Via methods kunnen aanroepende systemen acties in het OPC UA-object activeren, terwijl gebeurtenissen zich in het algemeen gedragen zoals men van MQTT en vergelijkbare technologieën mag verwachten.

Voor communicatie en interactie met de verschillende parameters en attributen in het OPC UA-object definieert de specificatie twee fundamentele benaderingen. Enerzijds is er een client/server-model gebaseerd op het SOA-principe (service-oriented architecture) . Een PLC die meetgegevens opslaat, kan bijvoorbeeld de rol van server vervullen. Clients zoals een tablet-app, een pc-dashboard of een analysetool kunnen deze gegevens vervolgens ophalen. Een dergelijke client/server-structuur is bekend uit andere gedistribueerde informatiesystemen. Een belangrijk aspect hierbij is dat het ophalen van meetgegevens van de server gebeurt via polling.
 

Met Pub(lish)/Sub(scribe) is een alternatief communicatieschema beschikbaar dat gericht is op gebeurtenis-gestuurd programmeren en fundamenteel vergelijkbaar is met de gebeurtenissystemen die in MQTT worden gebruikt. Het is vermeldenswaard dat informatie die in MQTT-brokers wordt ontvangen ook kan worden doorgestuurd naar OPC UA.
 

Ik raad een uitgebreid artikel aan te lezen over OPC UA-terminologie dat de concepten van OPC UA grondig introduceert.
 

Een OPC UA-servernetwerk fungeert ook als een verenigend systeem, waarbij het idee is dat vooral in complexe industriële automatiseringsprojecten informatie verspreid is opgeslagen over een groot aantal verschillende systemen.
 

In de specificaties voor een "global namespace model" benadrukt de OPC Foundation herhaaldelijk dat verschillende adresseringssystemen, zoals fieldbus en TCP/IP, worden genormaliseerd via het OPC-UA-framework. Het is ook belangrijk dat het model niet alleen de daadwerkelijke instanties bevat, maar ook de instantietypen die binnen het betreffende automatiseringssysteem voorkomen.

Een OPC UA-server in gebruik nemen

Ondanks de enorme aanwezigheid op de markt zijn er weinig gemakkelijk toegankelijke voorbeeldimplementaties van OPC UA-servers. In de volgende stappen zullen we vertrouwen op een containergebaseerd systeem dat is afgeleid van Microsoft Azure.

Ondanks de hierboven beschreven onafhankelijkheid spelen .NET-technologieën een bijzondere rol in de wereld van OPC UA. Zo is er de UA.NET-repository van de standaardisatieorganisatie, beschikbaar op, die referentie-implementaties van de standaard in .NET-technologieën biedt.

In de volgende stappen gebruiken we de demoserver die beschikbaar is via, omdat deze een reeks min of meer gebruiksklare objecten voor analyse biedt. Het is ook vermeldenswaard dat de Eclipse Foundation een vergelijkbaar product aanbiedt met de naam Milo; de Milo-democontainer is te vinden op.

In de volgende stappen gebruikt de auteur een werkstation met acht cores waarop Ubuntu 24.04 draait als testsysteem. De geïnstalleerde Docker-versie ziet er als volgt uit:

tamhan@TAMHAN18:~$ docker --version

Docker version 28.4.0, build d8eb465

Idealiter wordt de ingebruikname uitgevoerd met de volgende opdracht, die verschillende standaardinstellingen levert voor de PLC-implementatie die binnen de container draait:

tamhan@TAMHAN18:~$ docker run --rm -it -p 50000:50000 -p 8080:8080 --name opcplc mcr.microsoft.com/iotedge/opc-plc:latest --pn=50000 --autoaccept --sph --sn=5 --sr=10 --st=uint --fn=5 --fr=1 --ft=uint --gn=5 --aa --ut

Tijdens het eerste opstartproces downloadt docker de vereiste componenten uit de repository. Zodra het opstarten succesvol is afgerond, verschijnt het bericht PLC simulation started, press Ctrl+C to exit... in het terminalvenster. Laat het venster open om de PLC (programmable logic controller) actief en controleerbaar te houden. Tijdens het gebruik zal de container daar voortdurend statusinformatie weergeven.

De parameters --aa en --ut zijn belangrijk, omdat ze certificaatgebaseerde clientauthenticatie uitschakelen. OPC UA verschilt onder meer van de vorige versie, ook bekend als OPC DA, door strengere beveiligingsfuncties, die voor onze laboratoriumexperimenten minder handig zijn (zie).

De verbinding testen met een generieke client

Ontwikkelaars kennen deze situatie goed: wie bijvoorbeeld een Bluetooth LE-systeem online wil brengen, doet er verstandig aan eerst de server te analyseren met een Bluetooth LE-scanner. De formele structuur van OPC UA betekent dat er min of meer generieke scanners beschikbaar zijn.

Wij gebruiken UA Expert, beschikbaar via. Het is een "promotioneel aanbod" van Unified Automation: het bedrijf biedt SDK's aan waarmee ontwikkelaars programma's kunnen maken die communiceren met OPC UA in uiteenlopende programmeertalen. UA Expert is slechts één voorbeeld binnen de brede OPC UA-markt. Een regelmatig bijgewerkte lijst met aanvullende componenten is te vinden op.

Voordat de scanner, die beschikbaar is voor zowel Windows als Linux, kan worden gedownload, is registratie bij Unified Automation vereist. Linux-gebruikers ontvangen een .tar.gz-archief dat moet worden uitgepakt en vervolgens als volgt uitvoerbaar gemaakt en gestart moet worden:

tamhan@TAMHAN18:~/Downloads/UaExpert-2.0.1-x86_64-linux$ chmod +x UaExpert-2.0.1-x86_64.AppImage

tamhan@TAMHAN18:~/Downloads/UaExpert-2.0.1-x86_64-linux$ ./UaExpert-2.0.1-x86_64.AppImage

Tijdens de eerste start vraagt het systeem om een cryptografische identiteit aan te maken. Figuur 2 toont de voorbeeldinstellingen van de auteur.

Vervolgens moet u met de rechtermuisknop op de map Servers klikken en een nieuwe serverconfiguratie aanmaken. Omdat onze voorbeeldserver zijn diensten niet aanbiedt op de standaardpoort 4840, schakelen we over naar het veld Advanced. Onder Server Information  arrow Endpoint Url wordt de tekenreeks opc.tcp://localhost:50000 ingevoerd.

Nadat de verbinding succesvol tot stand is gebracht, zoals hierboven vermeld, maken de parameters --aa en --ut een onbeveiligde verbinding mogelijk. Het hieronder weergegeven namespace-venster is gevuld met de verschillende objecten, zoals getoond in Figuur 3.

UA Expert toont alle attributen die door de verschillende servers in dit overzicht worden aangeboden; in dit voorbeeld gebruiken we slechts een server.

Het OPC PLC-object (dat de PLC vertegenwoordigt) is bijzonder interessant; in Figuur 4 zien we de methodestructuur ervan. Door op de functies rechts te klikken, wordt een oproepvenster geopend. Figuur 5 toont hoe UA Expert een succesvolle methodeaanroep bevestigt.

Profielen en facetten

Een van de meest innovatieve aspecten van Bluetooth LE was het profielsysteem; dit maakte een flexibele, maar toch generieke implementatie van systemen mogelijk. Het idee is dat een "Systeem X" ten minste enkele attributen implementeert die de basisfuncties op een generieke manier beschikbaar stellen. Fabrikantspecifieke bijzonderheden kunnen worden gerealiseerd via aanvullende attributen die "transparant" lijken voor een onbekende tegenpartij.

OPC UA bevat een enigszins vergelijkbaar systeem. De basis bestaat uit OPC UA-datatypen: variabele typen die, vergelijkbaar met sterk getypeerde programmeertalen, gegevensformaten beschrijven over systemen en architecturen heen. Over het algemeen vindt u hier bekende typen zoals Integer, Boolean en andere, het onderwerp wordt samengevat in.

In de volgende stap komen we facetten tegen. Dit zijn interfaces die een specifieke functie definiëren. Het onderliggende idee is dat een systeem dat een bepaald facet implementeert, kan worden verwerkt door een gebruiker die hetzelfde facet verwacht. De overeenkomsten met Bluetooth LE-profielen of interfaces uit objectgeoriënteerd programmeren zijn niet toevallig.

Een niveau hoger bevinden zich de profiles, die in het geval van OPC UA een groep verplichte en optionele facetten samenvatten. Een lijst met algemene profielen is te vinden op. Branchespecifieke standaarden omvatten bijvoorbeeld OPC for woodworking, beschreven op, dat zich richt op de behoeften van de houtbewerkingsindustrie.

Bij de ontwikkeling van OPC UA-gecertificeerde systemen komt u ook de term Conformance Unit tegen. Een goede samenvatting van dit onderwerp is te vinden op.

open62541, open-source OPC UA-server

Iedereen die OPC UA in een commercieel project wil gebruiken, kan ondersteuning vinden bij verschillende bedrijven die min of meer gebruiksklare SDK's aanbieden.

Hoewel er proefversies beschikbaar zijn voor vrijwel alle stacks, verdient de volledig opensource open62541  speciale vermelding. Het is een klassieke C-gebaseerde OPC UA-stack. Op staat een (oudere) variant die de port naar de ESP-IDF-ontwikkelomgeving van Espressif illustreert.

Hoewel een volledige bespreking van het programmeren van de stack buiten de reikwijdte van dit artikel valt, willen we toch de kernconcepten introduceren. Technisch en conceptueel voelt open62541 aan als een mix van ESP-IDF en Palm OS. Een eenvoudige OPC-UA-server kan met de volgende code tot leven worden gebracht:

#include <open62541/server.h>

int main(void) {

  UA_Server *server = UA_Server_new();

  UA_Server_runUntilInterrupt(server);

  UA_Server_delete(server);

  return 0;

}

Bijzonder belangrijk hierbij is het object UA_Server. Het vertegenwoordigt een OPC UA-server in zijn geheel. In het huidige codevoorbeeld gaan we ervan uit dat het hostplatform multithreading ondersteunt. De aanroep runUntilInterrupt() creëert een thread die vervolgens de OPC UA-server beschikbaar stelt totdat deze via CTRL+C wordt beëindigd.

Als u een variabele aan de server wilt toevoegen, is de eerste stap het maken van een instantie van de klasse UA_VariableAttributes. Deze ontvangt vervolgens de verschillende attributen die beschikbaar moeten worden gesteld aan een OPC UA-client:

static void

addVariable(UA_Server *server) {

  UA_VariableAttributes attr =

       UA_VariableAttributes_default;

  UA_Int32 myInteger = 42;

  UA_Variant_setScalar(&attr.value,

      &myInteger, &UA_TYPES[UA_TYPES_INT32]);

  attr.description =

      UA_LOCALIZEDTEXT("en-US","the answer");

  attr.displayName =

      UA_LOCALIZEDTEXT("en-US","the answer");

  attr.dataType =

      UA_TYPES[UA_TYPES_INT32].typeId;

  attr.accessLevel = UA_ACCESSLEVELMASK_READ |

                     UA_ACCESSLEVELMASK_WRITE;

In de volgende stap wordt een containerstructuur gemaakt die de positie van de variabele binnen de namespace vastlegt. Tot slot wordt de methode addVariableNode() aangeroepen met een verwijzing naar het serverobject om de integratie van de variabele in het servergeheugen succesvol af te ronden:

  UA_NodeId myIntegerNodeId =

        UA_NODEID_STRING(1, "the.answer");

  UA_QualifiedName myIntegerName =

        UA_QUALIFIEDNAME(1, "the answer");

  UA_NodeId parentNodeId =

        UA_NS0ID(OBJECTSFOLDER);

  UA_NodeId parentReferenceNodeId =

        UA_NS0ID(ORGANIZES);

  UA_Server_addVariableNode(server,

          myIntegerNodeId, parentNodeId,

          parentReferenceNodeId, myIntegerName,

          UA_NS0ID(BASEDATAVARIABLETYPE),

          attr, NULL, NULL);

}

Natuurlijk kunnen waarden die in variabelen zijn opgeslagen later worden bijgewerkt. Hiervoor verwijzen wij u naar de tutorial op, waarin de verschillende benaderingen uitgebreid worden toegelicht.

Voor het implementeren van de hierboven getoonde methoden maakt deze stack gebruik van functiepointers. Ook hier biedt de gekoppelde documentatie aanvullende informatie over de programmeerparadigma's.

Conclusie

OPC UA kan worden beschouwd als een inspiratiebron voor het gegevensbeheerschema dat in Bluetooth LE wordt gebruikt. Wie zich het protocol voorstelt als "Bluetooth LE voor automatisering" vereenvoudigt de zaak misschien enigszins, maar zit er niet volledig naast. Over het algemeen is de interactie met OPC UA-technologie aanzienlijk eenvoudiger dan de enorme omvang van de standaarddocumentatie doet vermoeden.

De auteur en de redactie hopen dat deze beschouwingen lezers aanmoedigen om industriële automatisering verder te verkennen. Het is een enorme groeisector waarin hoge uurtarieven kunnen worden verdiend.

Vragen of opmerkingen?

Hebt u technische vragen of opmerkingen over dit artikel? Neem dan contact op met de auteur via tamhan@tamoggemon.com of met de redactie van Elektor via redactie@elektor.com.

 Noot van de redactie: Dit artikel (250864-01) is verschenen in Elektor juli/augustus 2026.