Learn Automation with MINATA #75: OPC UA — Model the Data Before Connecting the PLC Upwards

OPC UA: Model the Data Before Connecting the PLC Upwards

OPC UA is useful because it carries both the structure and the meaning of data, not merely a path for tags from a PLC to something else. That is exactly why its value comes from a designed information model, and not from opening an endpoint and exposing everything.

Model the information before opening an endpoint

Before connecting a PLC to SCADA, to an MES or to a cloud service, choose a minimal information model: machine identity, state, mode, alarms, production count, quality, recipe and version, and health. Every node needs its unit, timestamp, quality, read and write rights, and a clear owner. A small model that means something is far easier to work with than thousands of flat, undescribed tags.

Separate observation from control

Distinguish observed data clearly from commands. A client permitted to read the state is not thereby permitted to start the machine or change a setpoint. A control command over OPC UA needs its own state machine, authentication, audit, timeout and confirmation of the result. Never map a remote write straight onto a PLC coil: that is the shortest path to a dangerous command nobody is controlling.

Security is part of the design

OPC UA provides security mechanisms — certificates, encryption, access rights. Use them, rather than leaving the endpoint open. Who may connect, what they may read and what they may write all follow policy, and every connection should be loggable so it can be traced.

A worked engineering situation

A machine offers, over OPC UA, a model containing identity, PackML state, output, alarms and health. The MES reads those nodes for monitoring. When a command is needed — selecting a recipe, for instance — it passes through a state machine with authentication, a timeout and a result confirmation, rather than writing straight into a control variable. Integration upwards happens, and the machine keeps its authority.

The information model, the access rights and the security configuration all follow the integration requirements and the organisation's security policy.

Common mistakes

Opening an endpoint and exposing every flat tag, with no model.
Nodes lacking unit, timestamp, quality and owner.
Mapping a remote write directly onto a PLC coil.
Assuming a client that can read may also issue control commands.
Skipping certificates and encryption, leaving the endpoint unsecured.

OPC UA checklist

[ ] A minimal information model exists, meaningful and owned.
[ ] Every node carries unit, timestamp, quality and access rights.
[ ] Commands pass through a state machine with authentication, timeout and audit.
[ ] Observation and control are separated by permission.
[ ] Certificates, encryption and access rights are configured.

A good data model makes integration both durable and safe. #76 turns to MQTT in industrial IoT: designing topics and payloads before sending anything.

Read more automation knowledge at MINATA: https://minatavn.com/en/blog/industrial-automation

Previous — #74: Barcodes and traceability: https://minatavn.com/en/blog/automation-74-barcode-traceability

Next — #76: MQTT for industrial IIoT: https://minatavn.com/en/blog/automation-76-mqtt-industrial-iiot

View all MINATA technical articles