OPC UA Client Commissioning Checklist

Why OPC UA commissioning needs a checklist

OPC UA often looks simple during a demo: enter an endpoint, trust a certificate, browse tags, and start reading values. In production, the same connection may cross VLANs, pass through firewalls, rely on name resolution, enforce certificates, expose multiple security policies, and feed alarms or historian data. A connection that works from an engineering laptop is not automatically commissioned for a SCADA server.

Use this checklist when adding an OPC UA client in SCADA, HMI, historian, reporting, MES, or gateway software. The goal is not to replace the vendor manual. The goal is to catch the common field problems before the system is handed to operations.

Record the endpoint details

Start by writing down the exact endpoint used by the client. Do not rely on a screenshot alone.

Record:

OPC UA server hostname or IP address.
Endpoint URL, including protocol and port.
Server application name, if displayed.
Security policy and message security mode.
User authentication method.
Client application name.
Client machine name and IP address.
Expected update rate or publishing interval.
Contact for the device, PLC, package unit, or vendor system.

Many servers expose more than one endpoint. Some provide unsecured discovery endpoints plus secured endpoints for runtime use. During commissioning, confirm which endpoint is intended for production and document why it was selected.

Confirm network reachability

Before adjusting OPC UA settings, prove basic network access from the actual runtime machine. Test from the SCADA server, historian collector, or gateway that will run the client service. Testing only from a laptop can hide routing, firewall, or DNS problems.

Check:

The client can resolve the server hostname, if a name is used.
The required TCP port is reachable.
The route is allowed between the correct VLANs or zones.
Firewall rules are limited to the required source and destination where possible.
Time synchronization is working on both systems.

If the endpoint uses a hostname but the certificate contains a different name, some clients may warn or reject the connection depending on policy. Decide whether the system standard is to connect by DNS name, fully qualified domain name, or IP address, then keep it consistent.

Handle certificates deliberately

Certificate handling is one of the most common OPC UA startup delays. Avoid the habit of clicking through trust dialogs without recording what was trusted.

For each connection, confirm:

The client certificate is present on the server trust list.
The server certificate is present on the client trust list.
Rejected certificates have been reviewed, not blindly accepted.
Certificate expiration dates are known.
Certificate replacement procedure is documented.
Backup images or VM snapshots do not duplicate identities in a way that confuses trust.

Some plants use self-signed certificates. Others use a site certificate authority. Either can work if managed consistently. The dangerous case is an undocumented certificate store where nobody knows what will happen after a server rebuild, firmware update, or certificate expiry.

Select security policy and authentication

Use the strongest practical security settings supported by both ends and approved by the site standard. Older devices may only support limited options. If a weaker setting is required, document the reason and the network controls around it.

Review:

Security policy, such as None, Basic256Sha256, or vendor-supported alternatives.
Message security mode, such as Sign or SignAndEncrypt.
Anonymous, username/password, certificate, or other authentication.
Password storage method in the client configuration.
Whether the account has read-only or write access.

For a historian read connection, the account usually should not have write capability. For an HMI that writes setpoints, the write path should be limited, tested, and tied to operator permissions in the HMI layer.

Browse and map nodes carefully

Browsing the namespace is convenient, but the browse tree is not a control narrative. Names can change between firmware versions or project downloads. Treat node selection as a configuration item.

For each important tag, record:

Display name used by operators or engineers.
OPC UA NodeId.
Data type.
Engineering units, if provided.
Normal range or expected states.
Read/write requirement.
Source PLC tag or device point, if known.

Avoid mapping tags only because they appear nearby in a folder. Confirm meaning against the PLC program, vendor point list, or approved I/O list. This is especially important for package equipment where similar status bits may indicate command feedback, permissive state, fault state, or interlock state.

Validate data quality and timestamps

A value without quality is not enough. Commissioning should prove that the client displays or stores quality information correctly.

Test at least these conditions where safe:

Normal connected operation.
Server stopped or network path disconnected.
Device or PLC unavailable behind the OPC UA server.
Bad quality or uncertain quality, if the server exposes it.
Stale value behavior after communication loss.
Timestamp source used by the client.

For historian connections, decide whether source timestamps or server receive timestamps are used. Source timestamps can be useful, but only if device clocks are synchronized and trusted. For HMI displays, make sure stale or bad values are visibly different from good live values.

Tune update rates and subscriptions

A client can overload a small controller or gateway by subscribing to too much data too quickly. Start with the process need, not the maximum possible scan rate.

Separate points by purpose:

Fast operator feedback for active controls.
Normal HMI indication.
Alarm-related points.
Historian points.
Slow diagnostic or maintenance points.

Not every value needs a one-second update. Tank levels, energy totals, valve diagnostics, and nameplate data may tolerate slower intervals. Keep an eye on server diagnostics where available: sessions, subscriptions, monitored items, queue overflows, rejected requests, and communication errors.

Test writes before handover

If the client writes commands or setpoints, test the full path under controlled conditions.

Confirm:

Operator permissions are enforced.
Command buttons use confirmation where appropriate.
Setpoint limits are applied in the HMI and in the controller.
Failed writes are visible to the operator.
Write feedback is based on process or PLC confirmation, not only button state.
Accidental repeated writes do not create unsafe behavior.

Do not assume a successful OPC UA write means the process accepted the command. The controller may reject it due to mode, interlock, permissive, or local control status. The HMI should make that difference clear.

Keep a commissioning record

Finish by saving the client configuration, certificate notes, mapped tag list, and test results in the project record. Include screenshots only as supporting evidence; they should not be the only documentation.

A good OPC UA connection record lets the next engineer answer three questions quickly: what endpoint is this client using, what identities are trusted, and what plant data is expected to move across the connection. If those questions are easy to answer, future troubleshooting becomes much faster.