How Captia Connect speaks OPC UA
Connect behaves as an OPC UA client. The server sits on the other side: usually embedded in the PLC, in the machine controller or in the SCADA that is already installed. That asymmetry shapes everything else. Connect publishes nothing onto the plant network and requires no software on the controller; it connects to an endpoint that already exists, reads what it has been authorised to read and takes the data to the edge.
Transport and endpoint
The connection is made against a server endpoint URL of the form opc.tcp://address:port, over the binary TCP transport of the standard, with 4840 as the port the specification sets by default. Before reading anything, the client asks the server for the list of endpoints it offers: each one declares a security policy and a message mode, and that is where the guarantees of the conversation are decided. If the equipment publishes several endpoints, the Connect criterion is to take the most protected one the server actually accepts, not the first on the list.
The connection is outbound from the Connect node towards the server and stays inside the plant network. Outwards, the node opens no inbound ports: the link to the platform is established by Tailscale as a secure outbound connection. This is the practical difference that matters to whoever maintains the network: integrating OPC UA with Connect does not require publishing the PLC on the internet or opening a NAT towards the controller.
Data model: address space, nodes and subscription
An OPC UA server does not expose a flat list of addresses, it exposes an address space: a graph of nodes with an identifier, a type, a readable name and relationships between them. Connect browses it, which means it walks that hierarchy and shows what is there, instead of demanding that somebody dictate a list of addresses in advance. In practice this shortens commissioning: the conversation with the automation lead stops being "send me the map" and becomes "out of all this, what do we want".
With the chosen nodes, Connect subscribes. Subscription is the native working mode of the standard and works by notification: the server reports when the value of a monitored node changes, instead of the client asking again and again. Compared with polling, this reduces traffic on the plant network and load on the controller CPU, which is the resource that genuinely needs protecting on equipment in production.
Security
OPC UA carries security inside the protocol itself rather than delegating it to an external layer, and it comes down to three decisions to be made on every deployment: the security policy of the channel, which determines whether messages travel signed, signed and encrypted or in the clear; certificate trust, because client and server identify each other with a certificate and each must accept the other; and user authentication, with the read only account that applies. The operational recommendation is short: a signed and encrypted channel, the client certificate explicitly accepted on the server and credentials with no write permission. Connect acquires, it does not issue setpoints.
| Parameter | What is decided | Starting criterion |
|---|---|---|
| Endpoint | The opc.tcp address and port of the server, taken from the list the equipment publishes | The most protected endpoint the server genuinely accepts |
| Channel security | Security policy, message mode and mutual certificate trust | Signed and encrypted messages, with the client certificate explicitly accepted |
| Identity | The user the client authenticates with on the server | A dedicated read only account, never the engineering account of the equipment |
| Node selection | Which nodes of the address space are monitored and at what publishing interval | Only the signals that support a decision, at the interval that decision requires |
Which equipment exposes OPC UA
In a plant, OPC UA turns up in three places, and they are worth separating because the integration work differs in each.
The first is modern PLCs and controllers with an embedded server. The server is already in the equipment, often licensed and shipped disabled. Here the work is configuration: enable the server, define which variables are published and create the read account.
The second is existing SCADA systems. When the plant already has a SCADA with signals aggregated and named, its OPC UA server is usually the best tapping point: it avoids duplicating the mapping work somebody did years ago and respects the naming the operation already uses. The trade off is that data arrives with the granularity and aggregation the SCADA applies, not that of the process.
The third is OEM machines with OPC UA on their data interface, common on recent process equipment. They usually expose a closed set of variables, which is what there is, and that is what you work with.
Outside those three cases sits the equipment that does not speak OPC UA: older controllers, power analysers, drives and meters. For that fleet the route is Modbus, over TCP or over RTU on RS-485, and the two normally coexist in the same plant. The service that carries out that end to end data capture is PLC connectivity.
From OPC UA node to time series
What an OPC UA node returns is not a bare number. It is a value with its declared type, its source timestamp and a status code stating whether the reading is good, uncertain or bad. Connect preserves all three during normalisation, and that preservation is exactly what separates a defensible history from a table of numbers.
The type travels declared by the server, so there is no need to guess whether a register is a signed integer or a float, nor to apply scaling factors by hand. It is the structural advantage of OPC UA over a register protocol and it saves the class of error that shows up weeks later, when a temperature comes out multiplied by ten.
The source timestamp is the instant the signal was read at the plant, not the instant the data reached the platform server. It matters because of buffering: when connectivity drops and recovers, a block of delayed readings arrives at once from the local persistence of the edge. Stamped by arrival time, that block would compress the series and misrepresent the dynamics. Stamped by origin, every sample lands where it belongs.
The status code makes it possible to tell a real zero from a zero that is actually a failed sensor. A series that does not carry reading quality ends up feeding false alarms and models trained on gaps.
On top of that, the normalisation work is about identity: a node called ns=2;i=1043 can be read perfectly well, but nobody will know which decision it supports. Each signal is tied to its asset, line or area, and given a stable name and unit. That is the step that turns acquisition into a queryable history, and the one described in general terms by the data acquisition system guide.
| What the node delivers | What is done with it | What it is good for later |
|---|---|---|
| Value with a declared type | The type is preserved, with no manual conversions or scaling factors | Removes the scale and sign errors that surface weeks later |
| Source timestamp | Used as the sample timestamp, ahead of arrival time | The history keeps the real spacing between samples after a network outage |
| Reading status code | Carried alongside the value instead of being discarded | Allows a real zero to be told apart from a bad reading or a failed sensor |
| Address space node identifier | Tied to asset, line or area, with a stable name and unit | Makes the signal queryable by people who do not know the address space |
When OPC UA is not the right route
OPC UA is the standard that brings the most order to an OT integration, and even so there are four scenarios where insisting on it costs time and adds nothing.
The equipment has no OPC UA server. This is the most common case and there is no way round it: a fifteen year old controller, a power analyser or a drive will not expose one. Forcing it means buying an intermediate gateway that translates from another protocol, which adds something to maintain and a point of failure in exchange for nothing, because Connect already reads that equipment directly over Modbus.
The server is in the equipment but there is no licence, or the manufacturer does not enable it. It happens. In that case the decision is economic rather than technical, and reading over the route the equipment already offers usually works out better.
The data is produced by an IIoT device that publishes on its own. Battery powered sensors, gateways and equipment that push telemetry to a broker fit MQTT, which is pub/sub and does not require the device to maintain a server. Putting an OPC UA server on a sensor so that Connect can read it is building the problem backwards.
The data is not on the plant floor. If the signal lives in an ERP, an MES, a cloud application or a laboratory export, OPC UA has no part in it: the route is the standard integrations over REST API, webhooks or CSV.
And one limit that belongs to the brief rather than the protocol: OPC UA does not fix a data model nobody has defined. Variables having a type does not mean they have meaning. If the address space is full of inherited names and auxiliary variables, somebody has to decide which ones matter. That work is about context, not protocol, and it is the subject of the industrial data contextualisation guide.
Coexistence with the rest of the installation
A normal plant does not speak one protocol, it speaks the ones it accumulated. Connect is built for that reality: it acquires in parallel over every available route and lifts them into the same time series model, so that in the history a signal from a modern PLC over OPC UA, a consumption read from a meter over IEC 870-5-102 and a temperature pulled from a drive over Modbus all sit at the same level. Nobody needs to know which protocol a value came from in order to use it.
The most frequent coexistence is OPC UA alongside MQTT. They do not compete: OPC UA covers machinery and SCADA, where there is a server and an information model, and MQTT covers retrofitted sensors and gateways, which publish on their own. Which one suits a new architecture, and on what criteria, is the discussion in the OPC UA versus MQTT resource, which is where it is developed.
Migration usually runs in the opposite direction to what people assume. Modbus is rarely replaced by OPC UA across an existing fleet: what happens is that new equipment arrives already speaking OPC UA while the older fleet stays as it is for as long as it lasts. Hence the recommendation not to frame the integration as a protocol homogenisation project, which is expensive and which nobody asked for, but as an acquisition layer that accepts what is there. Once that layer exists, swapping a piece of equipment stops being a data problem.
The platform modules already work on that base, and the engineering project that deploys it is OT and IT integration.