OPC UA clients, servers and node identity

An OPC UA integration that reads the right value today can read the wrong one after a server update, because the identity it stored was not the one that lasts. An OPC UA server holds an address space: a set of nodes that describe equipment, its values and how they relate. A reliable integration identifies each value by its NodeId and namespace, and keeps the value's status and timestamps with it. This guide explains each of those identities, and how to accept one point before you add a hundred.

This guide is part of the OPC UA and MQTT series. It covers the usual session-based client and server exchange, not OPC UA PubSub.

Clients and servers

The OPC Foundation's overview (Part 1) separates the two roles. The server owns the address space and offers services on it. The client connects and uses those services. One application can be both: a gateway can read a PLC's server as a client, and offer its own server to a SCADA system. Those are two interfaces, and each needs its own specification and test. A wrapper that puts a UA server in front of an older OPC DA server is a common case; the OPC DA migration guide covers it.

Check each service that the project needs separately: Browse, Read, Write, subscriptions (monitored items), method calls and historical access. A successful read of one scalar value proves only that read works for that node and that user.

Endpoints and security

An endpoint URL such as opc.tcp://plc-line-a.example:4840/UA/Process identifies a connection, not a value. Each endpoint advertises, as its EndpointDescription:

• a security policy, the set of algorithms;
• a message security mode: None, Sign or SignAndEncrypt;
• the user token types it accepts: anonymous, user name and password, or certificate.

Two separate trust decisions follow. The client and the server must trust each other's application certificates. The server must then authorise the user. Trusting a certificate does not authorise a user, and a TCP connection that opens proves neither. Record the endpoint, the security policy and mode, the user identity and where each certificate is trusted.

NodeIds and namespaces

A NodeId identifies one node. It has a namespace index and an identifier:

The namespace index is a position in the server's NamespaceArray, and each position holds a namespace URI. Part 3 of the specification defines this relationship. The URI is the stable name. The index can change when the server's configuration or firmware changes:

Record the namespace URI with every NodeId in the point list. After any change to the server, check the NamespaceArray before you trust the old indexes.

A display name and a browse path are not NodeIds either. Use them to find a node, then record its NodeId.

The value, its status and its timestamps

A read returns a DataValue, which Part 4 defines. Keep all of it:

Rules for using them:

• Check the status first. A Bad value is not a measurement. Agree a rule for Uncertain.
• Keep the two timestamps apart. A steady value can keep an old source timestamp while the server confirms it again and again. "No change for an hour" does not mean "no communication for an hour".
• Check the data type. Record the declared type and whether it is an array. A UInt64 counter is valid in OPC UA but can lose precision in software that stores numbers as 64-bit floats.
• Know which timestamp your collector keeps. Some collectors record the server or source timestamp; others record their own read time. The timestamp guide explains the difference.

Accept one point, then expand

For the first point, write down the endpoint, security settings, user, namespace URI, NodeId, data type, unit, any scaling and the read interval. Then:

1. Compare the value with an independent reference while it changes.
2. Record the status code and the timestamps at the server, at the collector and at the final destination.
3. Stop the source, or the connection, with approval. The data must show a gap or a Bad or Uncertain status, not an old value with a new timestamp.
4. Restart the collector, and check that it reads the same node again.
5. Read a node that does not exist, and one that the user may not read. Each must fail clearly, not return another node's value.

Test writes separately, with the equipment owner's approval and an independent check of the physical result.

OPC UA with Edge

Edge on the ZGW-20 Gateway is an OPC UA client. It connects to an endpoint with the security policy and mode that the server offers (None, Sign or SignAndEncrypt), as an anonymous user, with a user name or with a certificate. It reads each variable node on a schedule, from once a second to once a day, and applies any multiplier and offset. Edge addresses each node by its full NodeId, including the namespace index, so check the index after any server change. Each value is timestamped when Edge reads it.