OPC-UA

OPC Unified Architecture is the primary way QUBIQ talks to PLCs, DCS and gateways. QUBIQ acts as an OPC-UA client, maintaining a pooled session per connection and subscriptions on behalf of every bound tag.

Configuration

Field	Description
Name	Connection identifier used by bindings and pipeline nodes.
Endpoint	The endpoint URL, e.g. opc.tcp://192.168.1.10:4840.
Security mode	None, Sign, or SignAndEncrypt.
Security policy	None, Basic128Rsa15, Basic256, Basic256Sha256. Match what the server offers.
Username / Password	Optional user-identity token. Leave blank for anonymous.
Certificate / Private key	Client certificate for certificate-based identity or encrypted channels.
Trusted thumbprint	The server certificate QUBIQ has been told to trust.
Trusted server name	The application name recorded when the certificate was trusted.

Discovering endpoints

Rather than guessing the security combinations a server supports, ask it:

Use Discover in the connection form (needs Create Connection). The response lists every endpoint the server advertises with its security mode, policy and certificate. Pick one and the form fills itself in.

This is the reliable way to resolve "connects with None, fails with SignAndEncrypt" — the server usually offers a different endpoint URL per security level.

Certificate trust

With Sign or SignAndEncrypt, QUBIQ must trust the server's certificate and the server must trust QUBIQ's.

Trusting the server:

Use Trust beside the discovered endpoint (needs Create Connection). Discovery returns the server certificate; trusting it records the thumbprint and application name on the connection. Subsequent sessions verify against exactly that certificate — a substituted certificate fails rather than silently connecting.

Being trusted by the server: most servers reject an unknown client on first attempt and place its certificate in a rejected list. Move it to the trusted store on the server, then retry. This is normal and is a one-time step per client.

None is for commissioning

Security mode None sends credentials and process data in the clear. Use it to prove reachability, then move to SignAndEncrypt with Basic256Sha256 before production.

Binding tags

An OPC-UA binding needs a connection and a node address — the NodeId, e.g. ns=2;s=Motor1.Speed, ns=3;i=1042, ns=2;g={...}. Pick it with the browse button beside the address rather than typing it.

Every OPC-UA tag is subscribed: the server sends a value when it changes, which shifts change detection to the server, cuts network traffic and gives you the server's own timestamps. Tags bound in the tag dialog subscribe with a 1000 ms publishing interval; a binding imported with a rate of its own keeps it. Tags of a connection that share a rate share a subscription group.

→ Protocol bindings

Large and busy servers Changed in 1.0.8

1.0.8 was load-tested against a server with 50,000 nodes changing every second. What changed:

• A large rate group is spread over several subscriptions. A server answers each publish request with one notification message per subscription, capped in size, so one subscription cannot carry tens of thousands of changes a second. A 50,000-item subscription delivered 43 of every 60 changes. Each subscription now holds at most 1,000 items, or fewer if the server advertises a lower limit; the server's limit on subscriptions per session is honoured, and once it is reached the remaining items go to the least-filled existing subscriptions. Every item is still monitored. The limits the server advertises are read once per session and logged.
• Items are created in chunks of 500, or fewer if the server advertises a lower per-call limit. Rebuilding a lost subscription used to send every item in one call, which most servers refuse at a few thousand nodes, and every value on the connection stopped until a manual reload.
• Values reach the gateway in batches rather than one message per change. At 50,000 changes a second the single-message path overflowed and lost values in bursts.
• A slow subscribe is waited for. Subscribing a large batch can legitimately take its time; the gateway used to give up after 15 seconds, mark the connection unreachable and never register the tags. It now waits up to 75 seconds for a subscribe.

A slow server is not a lost server Changed in 1.0.8

A busy server can answer a health read slowly while it is still publishing data. One health read slower than five seconds used to count as a lost connection: the session was torn down and every subscription rebuilt — tens of thousands of them, at exactly the moment the server had no capacity to spare.

Now, as established OPC-UA clients do, arriving subscription data counts as proof of life:

• A slow health read is tolerated while subscription data has arrived within the last 30 seconds.
• Without data, three consecutive missed health reads — about 30 seconds — declare the connection lost.
• A failure that proves the connection is gone — the session or secure channel closed or invalid, the connection refused or reset — fails at once.
• After a reconnect, subscriptions are rebuilt only if the session changed. A subscription the server drops on a surviving session goes silent, and it is re-established when its data stops.

A subscription status notice is not a connection failure. After a server restart (seen on Kepware) the server sends a status notice for subscriptions it transferred to the new session. That was reported as an error and marked the connection down, so it flapped up and down several times in a few seconds, stamping every tag Bad each time. The notice is now logged and the connection left up; a subscription that really is dead is caught when its data stops.

The connection's log line now carries the reason for every change of state.

When the OPC-UA worker restarts Changed in 1.0.8

The OPC-UA worker holds the subscriptions on behalf of every tag. What a reconnect does depends on whether it still holds them:

• The session came back inside a running worker. The worker rebuilds its own subscriptions; the gateway leaves the tags alone. It used to reload every tag one at a time as well, which only churned the subscriptions the worker was rebuilding.
• The worker itself restarted. It starts empty, and now asks for its subscriptions the moment it is up; the gateway resends them in bulk. Values came back in about 10 seconds in testing, against 50 seconds before, when nothing told the gateway until the next connection check.

A down server no longer delays the others either: subscriptions are queued per connection, and a connection whose server does not answer is skipped for 30 seconds rather than costing a connect timeout for every batch. With one OPC-UA server stopped, a healthy one used to wait three and a half minutes for its first values.

When a connection drops, a tag keeps showing its last Good value; a read failure no longer blanks it.

Browsing the address space

Browse (needs View Connections) walks the server's address space so you can pick nodes in the binding editor instead of typing NodeIds. Browse results include the data type, so QUBIQ can pre-fill the tag's data type correctly.

Node quarantine

If a subscribed node repeatedly fails — it was deleted, renamed, or its type changed — QUBIQ quarantines it rather than letting one bad node degrade the whole subscription. A quarantined node stops being requested; the rest of the subscription keeps working.

Action	Permission
List quarantined nodes	View Connections
Release specific nodes back into service	Edit Connection
Clear the whole quarantine	Edit Connection

Quarantine is a symptom, not a fix. Read the list after a PLC program download — it is usually a precise list of the addresses that changed.

Data types

OPC-UA types map onto QUBIQ tag data types directly: Boolean, SByte/Byte, Int16/UInt16, Int32/UInt32, Int64/UInt64, Float, Double, String, DateTime. Arrays are supported and carry their dimensions through to the tag.

Set the tag's data type to match the node's. A mismatch surfaces as a conversion failure with Bad quality rather than a silently wrong value.

Quality and timestamps

OPC-UA status codes map to QUBIQ tag quality:

OPC-UA status	Tag quality
Good	Good
Uncertain*	Uncertain
Bad*	Bad
Node not found	NotFound

Both the source timestamp (when the device sampled the value) and the server timestamp (when the OPC-UA server processed it) are carried through to scripts and the historian.

Troubleshooting

Symptom	Check
BadTcpEndpointUrlInvalid	The endpoint hostname must match what the server advertises — use the discovered URL, not the IP you typed.
Connects, then drops every few minutes	Session or subscription timeout too short relative to the publishing interval.
BadCertificateUntrusted	The server has not trusted QUBIQ's client certificate yet.
BadUserAccessDenied	Credentials are valid but the account lacks read/browse rights on the node.
Some tags Bad, most Good	Check the quarantine list — those nodes probably no longer exist.
Values update far slower than expected	The server may be clamping the requested publishing interval. Check the server's minimum, and the device's own scan time.

Next

→ MQTT & Sparkplug B · Binding tags