OPC-UA Information Modeling and Subscriptions: A Deep Dive for IIoT Engineers [2026]

If you've spent time wiring Modbus registers to cloud platforms, you know the pain: flat address spaces, no built-in semantics, and endless spreadsheets mapping register 40004 to "Mold Temperature Zone 2." OPC-UA was designed to solve exactly this problem — but its information modeling layer is far richer (and more complex) than most engineers realize when they first encounter it.

This guide goes deep on how OPC-UA structures industrial data, how subscriptions efficiently deliver changes to clients, and how security policies protect the entire stack. Whether you're evaluating OPC-UA for a greenfield deployment or bridging it into an existing Modbus/EtherNet-IP environment, this is the practical knowledge you need.

Why Information Modeling Matters on the Factory Floor

In a typical plastics processing plant, a single temperature control unit might expose 30+ data points: delivery temperature, mold temperature, return temperature, flow values, setpoints, PID tuning parameters, alarm thresholds, and actuator states like pump, heater, and vent status. With Modbus, these are just registers — 404000, 404002, 404004 — and the meaning lives in a PDF or a spreadsheet that someone hopefully keeps updated.

OPC-UA inverts this. Every data point lives inside a typed, hierarchical address space that describes not just the value but what kind of thing it is, what units it uses, how it relates to the physical equipment, and what operations are valid on it.

The Address Space: Objects, Variables, Methods

An OPC-UA server organizes everything into nodes:

• Object Nodes represent physical or logical things: a chiller, a blender, a dryer
• Variable Nodes hold actual data: temperature readings, setpoints, status flags
• Method Nodes expose callable operations: start a batch, reset an alarm
• ObjectType Nodes define templates: "this is what a TCU looks like"
• ReferenceType Nodes define relationships: "this variable belongs to that object"

Here's what a temperature control unit might look like in an OPC-UA address space:

Root/
  Objects/
    PlantFloor/
      TCU_Unit_001/
        DeliveryTemperature (Float, °F, Read)
        MoldTemperature (Float, °F, Read)
        ReturnTemperature (Float, °F, Read)
        FlowValue (Float, GPM, Read)
        Setpoint1 (Float, °F, Read/Write)
        Setpoint2 (Float, °F, Read/Write)
        PIDController/
          ProportionalBandHeat (Float, %, Read)
          ProportionalBandCool (Float, %, Read)
          Reset (Float, Read)
          Rate (Float, Read)
          PIDOutputPercent (Float, %, Read)
          HeaterOutputPercent (Float, %, Read)
          CoolingOutputPercent (Float, %, Read)
        Alarms/
          Alarm1Low (Float, °F, Read/Write)
          Alarm1High (Float, °F, Read/Write)
        Status/
          PumpStatus (Boolean, Read)
          HeaterStatus (Boolean, Read)
          VentStatus (Boolean, Read)
          SystemStandby (Boolean, Read)
        Autotune/
          State (Int32, Read)
          TuneDutyPercent (Float, %, Read)
          PeakOvershoot (Float, °F, Read)
          PeakUndershoot (Float, °F, Read)

Compare this to a flat Modbus register map. With OPC-UA, a client can browse the server, discover what's available, understand the data types, and even auto-configure dashboards — no PDF required.

Building Reusable ObjectTypes

The real power emerges when you define ObjectTypes. If your plant has 50 TCUs from the same manufacturer, you define the type once:

TCUType (ObjectType)
  ├── DeliveryTemperature : AnalogItemType
  ├── MoldTemperature : AnalogItemType
  ├── ReturnTemperature : AnalogItemType
  ├── FlowValue : AnalogItemType
  ├── Setpoint1 : AnalogItemType (Writable)
  ├── PIDController : PIDControllerType
  │     ├── ProportionalBand : AnalogItemType
  │     ├── IntegralPercent : AnalogItemType
  │     ├── DerivativePercent : AnalogItemType
  │     └── OutputPercent : AnalogItemType
  ├── Alarms : AlarmGroupType
  └── Status : DiscreteStatusType
        ├── PumpRunning : TwoStateDiscreteType
        ├── HeaterActive : TwoStateDiscreteType
        └── VentOpen : TwoStateDiscreteType

Then each physical unit is an instance of that type. Clients that understand TCUType can automatically configure monitoring for any unit in the plant without per-device setup.

Data Types That Actually Mean Something

OPC-UA doesn't just give you float and uint16. The AnalogItemType carries:

• EngineeringUnits: EUInformation with unit ID (e.g., UNECE code 4408 for degrees Fahrenheit)
• EURange: The valid operating range (e.g., 32.0 to 500.0°F)
• InstrumentRange: The sensor's physical limits
• ValuePrecision: How many decimal places are meaningful

This metadata travels with the data. A client displaying "425.3°F" knows it's temperature, knows the valid range, and can auto-configure gauge visualizations and alarm thresholds without human intervention.

Subscriptions: Efficient Real-Time Data Delivery

Polling is the enemy of scalable IIoT. If you have 200 machines each exposing 30 variables, polling every second means 6,000 requests per second to the OPC-UA server. Subscriptions eliminate this.

How Subscriptions Work

The subscription model has three layers:

1. Subscription: A container with a publishing interval (e.g., 1000ms)
2. MonitoredItems: Individual data points within the subscription, each with its own sampling interval
3. Notifications: Batched change reports sent at the publishing interval

Client → Server: CreateSubscription(publishingInterval: 1000ms)
Client → Server: CreateMonitoredItems([
    {nodeId: "TCU_001/DeliveryTemp", samplingInterval: 500ms, queueSize: 5},
    {nodeId: "TCU_001/MoldTemp", samplingInterval: 500ms, queueSize: 5},
    {nodeId: "TCU_001/PumpStatus", samplingInterval: 100ms, queueSize: 10}
])

The server samples internally at the requested rate, but only sends notifications when values actually change or when a deadband is exceeded — dramatically reducing network traffic.

Deadbanding: The Secret to Bandwidth Efficiency

For analog values like temperature and pressure, you don't need every 0.01° fluctuation. OPC-UA supports two deadband types:

Absolute Deadband: Notify only when the value changes by more than X units:

MonitoredItem: DeliveryTemperature
  DeadbandType: Absolute
  DeadbandValue: 0.5  // Only report changes > 0.5°F

Percent Deadband: Notify when the value changes by more than X% of the EURange:

MonitoredItem: FlowValue
  DeadbandType: Percent
  DeadbandValue: 2.0  // Only report changes > 2% of full scale

For a plant with 200 temperature sensors that typically drift ±0.1° per cycle, absolute deadbanding of 0.5° can reduce notification traffic by 80-90% while still catching every meaningful thermal event.

Queue Management and Data Loss Prevention

Each monitored item has a queue. When the sampling interval is faster than the publishing interval, values accumulate:

Sampling: 100ms (10 samples per second)
Publishing: 1000ms (1 notification per second)
Queue Size: 10

Between publishes, the queue holds up to 10 samples.
If queue overflows: oldest values are discarded (or newest, depending on config).

For critical binary states like pump status or alarm flags, you want the queue sized to never overflow — losing a pump-off/pump-on transition means losing visibility into an equipment fault. For analog values sampled at high rates, losing intermediate samples is usually acceptable.

Practical rule of thumb: Set queue size to at least (publishingInterval / samplingInterval) × 1.5 for any data point where transitions matter.

Subscription Keepalive and Lifetime

Subscriptions aren't permanent. The server expects the client to call Publish periodically. If the client goes silent:

• After maxKeepAliveCount × publishingInterval: Server sends empty keepalive notifications
• After lifetimeCount × publishingInterval: Server deletes the subscription and frees resources

In industrial environments with unreliable networks (cellular gateways, Wi-Fi bridges), set generous lifetime values:

publishingInterval: 1000ms
maxKeepAliveCount: 10        // 10 seconds before keepalive
lifetimeCount: 300           // 5 minutes before subscription death

This gives a cellular gateway 5 minutes to recover from a network interruption without losing its subscriptions.

OPC-UA Pub/Sub: The Next Evolution

Traditional OPC-UA is client/server: the client connects to the server, creates subscriptions, and receives data. OPC-UA Pub/Sub (Part 14 of the specification) decouples publishers from subscribers using a broker or multicast transport.

Why Pub/Sub Matters for Factory Networks

Client/server works well for 1-to-1 relationships: one SCADA system monitoring one PLC. But modern factories have:

• Edge gateways collecting from multiple PLCs
• Cloud platforms consuming the same data
• Local dashboards for operators
• Quality systems sampling production data
• Maintenance systems monitoring vibration and temperature

With client/server, each consumer maintains its own connection and subscription to the PLC's OPC-UA server. Five consumers × 30 tags = 150 active monitored items on a device that might have a 200-item limit.

Pub/Sub solves this: the PLC publishes once to a broker (typically MQTT or AMQP), and any number of consumers subscribe independently.

UADP vs JSON Encoding

Pub/Sub messages can be encoded two ways:

UADP (UA Data Protocol): Binary encoding, compact, ~40% smaller than JSON. Best for constrained networks:

Field               | Bytes
--------------------|-------
PublisherId          | 4
DataSetWriterId     | 2
SequenceNumber      | 2
Timestamp           | 8
Status              | 4
Value (Float32)     | 4
Total per value     | ~24 bytes

JSON Encoding: Human-readable, easier to debug, integrates naturally with cloud platforms:

{
  "MessageId": "msg-001",
  "PublisherId": "TCU_001",
  "DataSetWriterId": 1,
  "Payload": {
    "DeliveryTemperature": {"Value": 425.3, "SourceTimestamp": "2026-03-03T11:00:00Z"},
    "MoldTemperature": {"Value": 418.7, "SourceTimestamp": "2026-03-03T11:00:00Z"}
  }
}

For edge-to-cloud architectures, the pragmatic choice is often JSON encoding over MQTT — you get OPC-UA's rich data semantics with MQTT's ubiquitous broker infrastructure.

Combining Pub/Sub with MQTT Brokers

The most powerful pattern in 2026 is using OPC-UA Pub/Sub with an MQTT broker as the transport layer:

1. Edge gateway reads from PLCs via Modbus/EtherNet-IP (as most industrial equipment still speaks these protocols)
2. Gateway normalizes data into OPC-UA information models with proper types, units, and structure
3. Gateway publishes via MQTT with OPC-UA JSON encoding
4. Cloud platform subscribes and gets semantically rich data without direct PLC access

This is exactly the pattern that platforms like machineCDN implement — bridging legacy protocols to cloud-native infrastructure while preserving the semantic richness that makes data actually usable.

Security Policies: Protecting Industrial Data

OPC-UA has the most comprehensive security model of any industrial protocol. It operates at three layers:

Transport Security

Every OPC-UA connection can use:

• None: No encryption (only for isolated test networks)
• Basic256Sha256: AES-256 encryption with SHA-256 signatures
• Aes128_Sha256_RsaOaep: AES-128 with SHA-256 and RSA-OAEP key exchange
• Aes256_Sha256_RsaPss: The current recommended policy for new deployments

The client and server exchange X.509 certificates during the secure channel handshake. Both sides validate the certificate against their trust store before proceeding.

Application Authentication

Beyond transport encryption, OPC-UA authenticates the application itself:

• Application Instance Certificate: Identifies the specific software instance
• Trust Lists: Server maintains a list of trusted client certificates (and vice versa)
• Certificate Revocation: Compromised certificates can be revoked without changing network infrastructure

User Authentication

On top of the secure channel, users authenticate via:

• Anonymous: No user identity (appropriate for machine-to-machine with certificate-based app auth)
• Username/Password: Traditional credentials
• X.509 Certificate: User-specific certificates
• JWT Token: Integration with enterprise identity providers (OAuth2/OpenID Connect)

Practical Security Configuration

For a typical manufacturing deployment:

Endpoint Configuration:
  SecurityMode: SignAndEncrypt
  SecurityPolicy: Aes256_Sha256_RsaPss
  UserTokenPolicy: Certificate OR Username
  
Certificate Management:
  ServerCert: /etc/opcua/certs/server.der
  ServerKey: /etc/opcua/private/server.pem
  TrustList: /etc/opcua/trusted/
  RejectedList: /etc/opcua/rejected/
  
  Auto-accept: DISABLED (never in production)
  CRL Check: ENABLED

Critical lesson from real deployments: Many OPC-UA installations ship with Auto-accept: ENABLED for easy commissioning and never disable it. This means any client with any certificate can connect. Always disable auto-accept before going to production, and explicitly add trusted client certificates.

Performance Considerations

Server Capacity Planning

A typical OPC-UA server on embedded hardware (ARM Cortex-A, 512MB RAM) can handle:

• 1,000-5,000 nodes in the address space
• 500-2,000 active monitored items across all subscriptions
• 10-50 concurrent sessions
• Minimum sustainable publishing interval: 100-200ms

On PC-class hardware (x86, 4GB+ RAM):

• 100,000+ nodes
• 50,000+ monitored items
• 200+ concurrent sessions
• Minimum publishing interval: 10-50ms

Network Bandwidth

For a subscription with 100 analog values at 1-second publishing with absolute deadband:

Typical change rate with deadband: 30% of items per publish cycle
Items reporting: 30
Bytes per DataChangeNotification: ~50 bytes
Overhead (headers, sequence numbers): ~100 bytes per message
Total per second: (30 × 50) + 100 = ~1,600 bytes/s = ~13 kbps

Compare to Modbus polling the same 100 registers at 1-second intervals:

100 registers × 8 bytes per request-response = 800 bytes
Plus TCP overhead: ~5,400 bytes/s = ~43 kbps

OPC-UA subscriptions with deadbanding use roughly 70% less bandwidth than equivalent Modbus polling for slow-moving process variables. For fast-changing values (vibration, current draw), the savings are smaller but the semantic richness still justifies the overhead.

When to Choose OPC-UA vs. Other Protocols

Scenario	Recommended Protocol	Why
Legacy PLCs with limited firmware	Modbus TCP/RTU	Already speaks it natively
Allen-Bradley / Rockwell	EtherNet/IP	Native protocol, best performance
Multi-vendor, semantically rich data	OPC-UA	Information modeling eliminates mapping
High-frequency data to cloud	MQTT (possibly with OPC-UA pub/sub encoding)	Lightweight, broker-based, QoS
Siemens S7 ecosystem	OPC-UA or PROFINET	Both well-supported
New greenfield IIoT deployment	OPC-UA with MQTT pub/sub transport	Best of both worlds

Practical Implementation Checklist

1. Define your ObjectTypes first — model the equipment, not just the tags
2. Use companion specifications — OPC Foundation publishes models for plastics (Euromap 77/83), CNC (MTConnect), packaging, and more
3. Set deadbands early — default to 1% percent deadband for analog values, adjust per use case
4. Size subscription queues for your network — cellular links need larger queues and longer lifetimes
5. Certificate management is operational — plan for renewal, revocation, and trust list distribution before deployment
6. Test failover — what happens when the OPC-UA server restarts? Do clients automatically re-subscribe?
7. Monitor subscription health — track notification queue depths and publish retransmissions

Conclusion

OPC-UA's information modeling transforms industrial data from opaque register values into self-describing, semantically rich structures that machines and humans can understand without external documentation. Combined with efficient subscription-based delivery and enterprise-grade security, it's the protocol that bridges the gap between shop floor PLCs and cloud-native analytics.

The practical reality in 2026 is that most factories run a mix of protocols — Modbus on legacy equipment, EtherNet/IP on Rockwell controllers, and OPC-UA on newer installations. Platforms like machineCDN bridge this heterogeneity by normalizing data from any source into consistent, structured models that work whether your equipment speaks century-old serial protocols or cutting-edge pub/sub.

The key insight: invest time in information modeling before writing a single line of integration code. A well-designed OPC-UA address space pays dividends for years. A flat register map creates technical debt that compounds with every new machine you connect.