What OPC UA is
OPC UA stands for OPC Unified Architecture. It is a specification from the OPC Foundation, also published as IEC 62541, for how industrial equipment and software describe data to each other and exchange it. A controller, a drive, a gateway or a piece of software that serves it can be read by any client that speaks it, without either side knowing anything about the other's make.
It is the successor to OPC Classic, the earlier family of specifications, Data Access and Historical Data Access among them. Those were built on Microsoft's COM and DCOM, which tied them to Windows and made them awkward to run across a network. OPC UA was written to be independent of any operating system and to carry its own security, and it is the form new controllers and gateways commonly expose.
The specification is in parts, each covering one thing: the address space (Part 3), the services a client can call (Part 4), data access (Part 8), historical access (Part 11) and publish-subscribe (Part 14) are the ones a reader of this page is most likely to meet. Companion specifications, written with industry bodies, add standard models for particular kinds of equipment on top.
Servers, clients, nodes and tags
Over a session, everything in OPC UA is one of two roles. A server holds the data and describes it; a client connects to a server, reads what it describes, and asks to be told when it changes. A controller with a built-in server, a gateway in front of older kit, an OPC server product that translates another protocol, and a supervisory system where it exposes one, are all servers. Opcela Quality is a client.
The address space
What a server exposes is a set of nodes, joined by references into a structure a client can browse. A folder is a node, a machine is a node, a value on that machine is a node. The server describes its own structure, so a client can discover what is there rather than being told in advance.
A tag is a variable node
What a plant calls a tag, the specification calls a variable: a node that holds a value. Every value comes with a data type, a timestamp, and a status code saying whether the reading is good, bad or uncertain. That status code is what the searches for an OPC UA quality code are about; it is a flag on a reading, and it has nothing to do with quality management.
A node id
Each node is addressed by a node id, which is a namespace and an identifier inside it. The identifier can be a number, a string, a GUID or an opaque value, and the namespace says which vocabulary it belongs to, so the standard's own nodes and a maker's own can each have a node numbered 1001 in the same server without colliding.
A session
A client opens a secure channel to a server's endpoint, then a session on top of it, and everything else happens inside that session: browsing, reading, writing, calling a method, or subscribing. The session is what the server authenticates and what it closes when the client goes away.
Subscriptions, and why a client does not poll
The part of OPC UA that matters most for monitoring is the subscription. A client creates a subscription on its session, adds the nodes it cares about as monitored items, and states how often the server should sample each one and how often it should publish. From then on the server sends the client what has changed, and only what has changed, at the publishing interval. A client can also set a deadband, so a value that flickers by a fraction is not reported at all.
That is different from polling, where a client reads every value on a timer whether or not it has moved. A subscription costs less on the network, puts the sampling where the value lives, and reports every change the server sampled rather than whichever value happened to be there when the client asked. It is how Opcela Quality reads a tag.
Security
Every OPC UA server publishes one or more endpoints, and each endpoint states the security it offers: a security policy, which is the set of algorithms, and a security mode, which is whether messages are signed, signed and encrypted, or neither. Client and server identify each other with X.509 digital certificates, and a server will refuse a client presenting one it has not been told to trust. A user can then be authenticated on the session in their own right, by name and password or by a digital certificate of their own. The usual transport is the binary encoding over TCP, and the port registered for it is 4840.
OPC UA beside the other protocols
The comparisons people search for most are with the two protocols they are most likely to have on site already.
OPC UA and Modbus
Modbus is far older and far simpler. It moves sixteen-bit registers and single-bit coils from a device that has no way of saying what a register means, what type it holds, or when it last changed, and the base protocol has no security. Everything about the meaning of the data lives in a spreadsheet beside the project. OPC UA carries the name, the type, the timestamp and the status with every value, and secures the connection. Plenty of equipment speaks both, and a gateway or an OPC server product is the usual way to bring a Modbus device into an OPC UA address space.
OPC UA and MQTT
MQTT is a publish-subscribe messaging protocol. A publisher sends a message to a broker under a topic, and every subscriber to that topic receives it. It is light and it scales well, and it says nothing at all about what is inside the message: the payload is whatever the publisher chose, so two senders need a separate agreement on its shape. Sparkplug B is one such agreement, fixing the topic layout and the payload format on top of MQTT. OPC UA defines the data model as well as the transport, and since Part 14 it can publish over MQTT itself. The two are not rivals so much as answers to different questions: one is a message bus, the other is a description of the plant.
OPC UA and OPC DA
OPC DA is the classic Data Access interface OPC UA replaced. It does the same job of reading and writing live values, but it is a Windows COM interface, so it needs a Windows machine at each end and DCOM configured between them. A wrapper or a gateway can present a DA server as a UA one, which is how a great deal of older kit is still read today.
Where it sits in the plant
The usual way to draw a plant is in levels, from the process at the bottom to the business systems at the top, in the arrangement the ISA-95 standard describes: the physical process at level zero, the sensors and actuators at level one, the controllers at level two, operations management at level three, and planning at level four. OPC UA is one of the ways level two exposes what it knows, and one of the ways the levels above read it.
Opcela Quality reads from that layer and does not take it over. The control layer stays with whoever holds it; the software is a client of it.
What Opcela Quality does with it
Opcela Quality is an OPC UA client that watches tag values and does something when they meet a condition. You choose the tags and set the condition on screen, a tag going high, for instance. The software subscribes to those tags and evaluates the condition itself, on the values it receives, so the server has to do nothing more than serve them.
When the condition is met, a workflow runs. One named person is told, by SMS, by WhatsApp or by email to the details on their own profile, and asked to approve. The approval is recorded, and the reports and signoff certificates come out of that record. A condition on a tag is how an alarm is expressed here: a tag going high is an alarm, and what follows it is the half this product is about.
Two things it is not, so that nobody has to ask. It is not a historian: it does not exist to store and serve the history of every tag, which is what Part 11 of the specification and a historian product are for. It keeps the record of what it raised and what was decided about it. And it is not tied to any maker of equipment. It speaks OPC UA, so it talks to whatever exposes an OPC UA server, whether that is a controller with one built in, a supervisory system, or an OPC server product standing in front of older kit.