OPC UA is often introduced as a way to read PLC tags from another system. That description is technically correct but incomplete. The real value of OPC UA is the ability to publish structured information about equipment, its state, and the meaning of its data.

From tags to information

A flat list of tags may look like this:

Temp_01
Temp_02
Motor_01_Run
Motor_01_Fault

An information model can describe the same equipment more clearly:

Factory
└── Line_01
    └── Panel_A
        ├── Temperature
        │   ├── Value
        │   ├── Unit
        │   └── Quality
        └── Motor_01
            ├── Running
            └── Fault

The second structure helps SCADA, historians, dashboards, and maintenance applications understand what they are reading.

Server and client roles

In a typical CODESYS architecture:

  • The CODESYS controller may expose process data through an OPC UA Server.
  • A SCADA, engineering tool, or analytics platform may act as an OPC UA Client.
  • A CODESYS application can also consume data from another OPC UA Server when required.

The role should be decided for each data flow. A system can contain multiple servers and clients, but every connection should have a defined owner, purpose, and security policy.

Subscriptions are better than constant polling

An OPC UA Client can repeatedly read values, but subscriptions allow the client to receive updates when monitored values change. This can reduce unnecessary traffic and make event-driven monitoring easier.

When designing a subscription, consider:

  • Sampling interval
  • Publishing interval
  • Deadband or change threshold
  • Queue size
  • Behavior during communication loss

Fast-changing control data and slow-changing diagnostic data rarely need the same update rate.

Certificates and trust lists

OPC UA security should be designed before commissioning. Encryption and authentication are only useful when certificates are managed consistently.

At minimum, document:

  1. Who issues or approves certificates
  2. Which client and server certificates are trusted
  3. How expired certificates are replaced
  4. Which user roles can read or write data
  5. How rejected connection attempts are diagnosed

Avoid treating certificate warnings as obstacles to be bypassed. They are part of the connection’s identity and trust model.

Write access deserves special attention

Not every value that can be read should be writable. A practical model separates:

  • Read-only process values
  • Operator-adjustable parameters
  • Engineering configuration
  • Safety- or maintenance-protected values

Write permissions should be assigned to the smallest group that needs them. The HMI, SCADA, and cloud applications should not automatically receive the same privileges.

OPC UA review checklist

  • Is the namespace organized around equipment and meaning?
  • Are units and quality states available where required?
  • Are update rates appropriate for each data group?
  • Are certificates and trust lists documented?
  • Is write access limited and auditable?
  • Does the client have a defined response to stale or bad-quality data?

Conclusion

OPC UA becomes much more useful when the controller publishes an understandable model instead of a random collection of tags. A clear information model reduces integration effort and creates a better foundation for future analytics and IIoT applications.

Next, we will compare REST API and MQTT and show where each fits in a CODESYS-to-cloud architecture.