43  OPC-UA Standard

43.1 Start With the Story

Picture a machine model that needs to be understood by software beyond the original controller. OPC UA becomes useful when the story is semantic interoperability: expose state, commands, alarms, and metadata in a way that another system can trust and maintain.

43.2 Learning Objectives

After completing this chapter, you will be able to:

• Explain OPC-UA architecture and its role in industrial integration
• Analyze the OPC-UA information model and node structure
• Compare client-server and publish-subscribe communication patterns
• Implement OPC-UA security features including authentication and encryption
• Design OPC-UA-based systems for IT/OT integration

For Beginners: OPC-UA Standard

OPC-UA is like a universal translator for factory machines. In most factories, different machines from different manufacturers speak their own “languages” and cannot talk to each other. OPC-UA gives them a common language so a robot arm, a temperature sensor, and a cloud computer can all share information securely. If you have ever used a USB cable that works with many different devices, OPC-UA does the same thing but for industrial communication.

43.3 Prerequisites

Before diving into this chapter, you should be familiar with:

• Industrial Protocols: Understanding of legacy and modern industrial protocols
• Industry 4.0 Fundamentals: Core concepts of Industry 4.0 and ISA-95 automation levels
• Networking Basics: TCP/IP and client-server communication patterns

Chapter Roadmap

This chapter moves from meaning to release evidence:

1. First you learn why IEC 62541 is more than a wire protocol: it gives industrial values names, units, quality, timestamps, and relationships.
2. Then you compare client-server and PubSub patterns so SCADA, historians, MES, CMMS, analytics, and cloud systems get the right interaction.
3. Next you secure the route with certificates, user roles, signing, encryption, trust lists, and audit evidence.
4. Finally you tune subscriptions, use companion specifications, and test a brownfield migration without flattening every source into raw tags.

Checkpoints recap the governing decisions. Interactive calculators and quizzes count as breathers; use them before moving to the next design layer.

43.4 OPC UA Shared Meaning

OPC Unified Architecture, standardized as IEC 62541, is not just another wire protocol. Its main value is that it lets a machine describe what its data means. A client can browse a server, find an asset, read variables, inspect units and data types, and discover methods without relying on a spreadsheet of vendor-specific register numbers. That makes OPC UA especially useful when a factory needs data to survive vendor changes, PLC upgrades, and multiple generations of analytics tools.

That matters in plants where equipment comes from many vendors and must connect to SCADA, HMI, historian, MES, CMMS, analytics, and cloud systems. A conveyor drive, robot cell, chiller, or packaging machine can expose a structured address space instead of forcing every integration team to reverse-engineer tags from scratch. A temperature value is more useful when the client can also discover the asset it belongs to, its engineering unit, its timestamp, its quality code, and whether it is read-only, writable, or part of a method call.

The practical design question is not “Can the server expose data?” but “Can downstream systems understand and trust it?” A good OPC UA deployment names the consumer, the operational risk, the namespace owner, and the change process. It separates monitoring from control writes, defines which values are authoritative, and documents which data can leave the control network through an edge gateway or DMZ broker.

• Address space: Organizes objects, variables, methods, references, and metadata into a browsable model.
• Security: Uses application certificates, secure channels, user authentication, signing, and encryption instead of assuming a trusted plant network.
• Integration: Supports request-response access for SCADA/HMI and publish-subscribe patterns for larger telemetry flows.

For learners, the important shift is from tag collection to information modeling. A raw register list might say that register 40017 is a number. An OPC UA model should help a client understand that the number is a motor current, measured in amperes, sampled from a specific drive, valid at a specific time, and linked to the packaging line where maintenance decisions are made.

43.5 Model Before Wiring Tags

A practical OPC UA project starts by deciding which objects the client should see. Model assets such as Line 3, Filler 2, Motor M101, TemperatureSensor A, or BatchRecipe as meaningful objects, then attach variables and methods that operators, engineers, and applications can interpret. Avoid publishing thousands of raw PLC tags with names that only the control engineer understands. The model should reflect how the plant is operated: line, cell, station, equipment, sensor, actuator, recipe, alarm, and maintenance context.

The integration choice depends on the consumer. A SCADA display may use client-server subscriptions to monitor selected nodes at a defined sampling interval. A plant historian may collect normalized values with engineering units and quality flags. A cloud analytics pipeline may receive OPC UA PubSub messages over MQTT through an edge gateway or DMZ broker rather than opening inbound access to control networks. MES and maintenance systems may need ISA-95 equipment hierarchy or companion specifications so production orders, downtime events, and asset records use the same vocabulary.

1. Name the consumer. Identify whether the data is for HMI, SCADA, MES, CMMS, historian, engineering analytics, or a cloud service.
2. Choose the interaction. Use browse/read/write/call/subscription for direct operational clients; use PubSub when many downstream consumers need decoupled streams.
3. Set the security baseline. Use current policies such as Basic256Sha256 or Aes256-Sha256-RsaPss, manage X.509 certificates, and disable Security Policy None outside isolated tests.
4. Reuse standard models. Check companion specifications such as OPC UA for Machinery, Robotics, PackML, PLCopen, MTConnect, and ISA-95 before inventing custom node structures.

Practitioners also need an operating model. Decide who issues and trusts application certificates, who approves writable nodes, who maps roles to user identities, who validates namespace changes, and how clients are tested before production. Tools such as UaExpert are useful for inspection, but production readiness usually needs source-controlled model definitions, documented namespace versions, certificate lifecycle procedures, and a rollback plan for server updates.

For brownfield systems, use gateways deliberately. A Modbus, PROFIBUS, PROFINET, EtherNet/IP, or vendor-driver gateway should not simply relay every register as a flat tag. It should attach asset names, units, quality, timestamps, and references so the new OPC UA layer creates a stable interface while the underlying equipment remains unchanged.

43.6 OPC UA Reads Semantics

Inside an OPC UA server, each node has a NodeId, BrowseName, DisplayName, NodeClass, attributes, and references to other nodes. A variable can carry a DataType, ValueRank, engineering unit, quality status, timestamp, and access level. References such as HasComponent, HasProperty, Organizes, and HasTypeDefinition make the model navigable instead of flat. Namespaces keep vendor, standard, and site-specific definitions separate, which is why careless NodeId churn can break historians, dashboards, and analytics jobs after a PLC or server update.

OPC UA information model hierarchy showing objects, variables, methods, properties, and references.

Figure 43.1: OPC UA information model: clients can browse structured nodes and references so industrial values carry asset context, units, quality, and operational meaning.

The secure channel is also part of the design, not a later wrapper. Applications exchange certificates, negotiate a security policy, create sessions, authenticate users, and authorize operations. Production servers need certificate rotation, trust-list management, user-role mapping, time synchronization, and clear rules for writable nodes because a write to the wrong setpoint can affect real equipment. Security Policy None is acceptable for a classroom lab but is not a production baseline for plant or pharmaceutical systems.

OPC UA communication choices change the failure mode. Client-server subscriptions maintain monitored items, queues, publishing intervals, keep-alives, and sequence numbers. PubSub decouples publishers from subscribers and may use UADP or JSON mappings over UDP, MQTT, or other transports depending on the deployment. Neither pattern removes the need for data-quality handling: clients still need source timestamps, server timestamps, status codes, stale-data detection, and explicit behavior when a gateway restarts or a subscription queue overflows.

Implementation choices are concrete. Teams commonly test models with clients such as UaExpert, build servers or clients with SDKs such as open62541, Eclipse Milo, node-opcua, or vendor SDKs, and bridge legacy Modbus, PROFIBUS, PROFINET, or EtherNet/IP systems through gateways. The difficult work is making the published model stable, secure, and useful across the equipment lifecycle.

• Model stability: Version namespaces and NodeIds deliberately so dashboards and historians do not break after every PLC or server update.
• Data quality: Preserve source timestamp, server timestamp, quality code, engineering unit, and operating state alongside the value.
• Boundary control: Keep read-only monitoring separate from write methods and control actions unless the authorization, safety, and change process are engineered for writes.

A reviewer should be able to trace one value from PLC or gateway source, through OPC UA namespace, secure session or PubSub route, historian or SCADA consumer, and final operational decision. If that trace loses units, quality, ownership, or write authorization, the deployment is only connected, not integrated.

Checkpoint: Shared Meaning

You now know:

• OPC UA is standardized as IEC 62541 and should preserve meaning, not just move values.
• A useful node carries context such as asset, engineering unit, timestamp, quality code, access level, and references.
• The first design question is the consumer and risk: HMI, SCADA, MES, CMMS, historian, analytics, cloud service, or approved write path.

43.7 Introduction

OPC Unified Architecture (OPC-UA) is the leading standard for industrial interoperability, designed to bridge IT and OT systems. Unlike proprietary protocols that lock users into specific vendor ecosystems, OPC-UA provides a vendor-neutral, platform-independent foundation for secure industrial communication.

OPC UA Standard Basics

Core Concept: OPC-UA (Open Platform Communications Unified Architecture) is a vendor-neutral, platform-independent standard for secure industrial communication that provides semantic data modeling, built-in security, and both client-server and publish-subscribe communication patterns for bridging IT and OT systems.

Why It Matters: Industrial environments contain equipment from dozens of vendors, each with proprietary protocols and tag naming conventions. Without a shared model, every integration can become a custom mapping and revalidation project. With OPC-UA and companion specifications, teams can expose repeatable information contracts that make commissioning, diagnostics, and analytics easier to govern.

Key Takeaway: OPC-UA is a semantic integration layer for industrial systems. Use client-server mode for operational clients such as SCADA and HMI, PubSub for decoupled telemetry paths, and companion specifications when the domain already has a tested model. Treat certificate trust, user roles, namespace versioning, and write authorization as part of the design, not optional deployment details.

Universal Translator Story

Hey there, young engineer! Bella the Bridge Builder has a big challenge at the Smart Factory!

The Problem: Imagine you have a classroom where some kids speak English, some speak Spanish, some speak French, and some speak Japanese. Nobody can understand each other! That is exactly what happens in factories – every machine speaks its own “language” (protocol).

Bella’s Solution – OPC-UA! Bella builds a Universal Translator that can talk to ALL the machines:

• The robot arm speaks PROFINET (like German)
• The temperature sensor speaks Modbus (like French)
• The conveyor belt speaks EtherCAT (like Japanese)
• The cloud computer speaks MQTT (like English)

OPC-UA is like a super-smart translator who speaks ALL these languages and helps everyone understand each other!

How It Works (Simply):

1. Self-Describing: Each machine tells OPC-UA what it can do – like a kid introducing themselves: “Hi, I’m a temperature sensor. I can tell you how hot things are!”
2. Secure: OPC-UA uses secret codes (encryption) so nobody can sneak in and give wrong instructions to the machines
3. Flexible: It works whether you want to ask a machine a question (client-server) or have machines shout updates to everyone who is listening (pub-sub)

Sensor Squad Memory Trick:

• OPC-UA = Universal Translator (speaks every factory language)
• Client-Server = Asking a question and getting an answer
• Pub-Sub = Shouting news so everyone hears it
• Companion Specs = Phrase books for specific industries

43.8 Why OPC-UA?

Time: ~12 min | Difficulty: Advanced | Unit: P03.C06.U04

Key Concepts

• Address Space: Browsable OPC UA structure containing objects, variables, methods, views, references, and type definitions.
• NodeId: Stable identifier for a node; careless NodeId churn can break historians, dashboards, and integrations.
• Reference: Typed relationship such as HasComponent, HasProperty, Organizes, or HasTypeDefinition that makes the model navigable.
• Secure Channel: Message-security context negotiated between applications using endpoint policy, certificates, signing, and encryption.
• Session: Authenticated client context used to browse, read, write, call methods, and manage subscriptions.
• Monitored Item: Subscription item that defines sampling, queueing, dead-band behavior, and notification rules for a node.
• Companion Specification: Domain model, such as PackML or OPC UA for Machinery, that standardizes node types and semantics for an industry or equipment class.

Traditional industrial protocols were designed for specific vendors or applications, creating integration challenges. OPC-UA provides:

• Platform independence: Works on any OS, hardware, or programming language
• Semantic data modeling: Self-describing data with context and relationships
• Built-in security: Authentication, encryption, and audit logging
• Scalable: From embedded devices to cloud servers
• Service-oriented: Multiple communication patterns (client-server, pub-sub)

43.9 OPC-UA Architecture

OPC-UA Client-Server Architecture

Figure 43.2: OPC-UA servers expose address-space nodes and service sets through secured sessions so SCADA, HMI, MES, and ERP clients can browse, read, subscribe, write, and call methods according to policy.

43.10 Information Model

OPC-UA’s information model is object-oriented and hierarchical:

Core concepts:

• Nodes: Objects, variables, methods, views
• References: Relationships between nodes (HasComponent, HasProperty, etc.)
• Attributes: Metadata (NodeId, BrowseName, DisplayName, Value, etc.)
• Data types: Built-in and custom types

Example hierarchy:

OPC-UA Information Model Hierarchy

Figure 43.3: The information model gives clients more than a value: it exposes type, unit, timestamp, quality, method, property, and relationship context.

This self-describing model means clients can discover capabilities without prior knowledge of the device.

43.11 Communication Patterns

OPC-UA client-server communication

Figure 43.4: Client-server communication separates discovery, read/write access, subscriptions, notifications, and secure-channel handling.

OPC-UA supports two communication patterns: client-server for direct request-response interaction (ideal for SCADA and HMI), and publish-subscribe for scalable, decoupled cloud integration.

43.11.1 Client-Server (Request-Response)

The traditional OPC-UA communication pattern:

• Client discovers server capabilities
• Client reads/writes values
• Client subscribes to data changes
• Server notifies client of changes
• Good for: SCADA systems, HMIs, configuration tools

Typical workflow:

1. Connect: Client establishes secure session with server
2. Browse: Client explores server’s address space to discover nodes
3. Read: Client reads current values of variables
4. Subscribe: Client creates subscriptions for data change notifications
5. Monitor: Server sends notifications when subscribed values change
6. Write: Client writes new values to writable nodes
7. Call: Client invokes methods on the server

43.11.2 Publish-Subscribe (Pub-Sub)

Modern OPC-UA extension for scalable communication:

• Publishers send data to broker (MQTT, AMQP)
• Subscribers receive data from broker
• Decoupled, scalable, firewall-friendly
• Good for: Cloud connectivity, analytics, mobile monitoring

Pub-Sub advantages:

• Scalability: One publisher, thousands of subscribers
• Decoupling: Publishers don’t need to know subscribers
• Firewall-friendly: Outbound connections only
• Cloud integration: Native MQTT/AMQP transport

Checkpoint: Communication Pattern

You now know:

• Client-server fits direct browse, read, write, call, subscription, SCADA, HMI, and configuration workflows.
• PubSub fits decoupled telemetry over MQTT or AMQP when cloud analytics should not maintain direct sessions to machines.
• A 500-machine factory often needs both: operational client-server locally, aggregated PubSub through edge gateways for cloud consumers.

43.12 Security Features

OPC-UA has security built-in from the ground up:

OPC-UA security trust record

Figure 43.5: OPC-UA security needs certificate ownership, trust-list management, user identity, authorization roles, and endpoint policy evidence, not only a checkbox that says encryption is enabled.

OPC-UA security operates in layered defense: transport encryption protects the channel, application certificates authenticate endpoints, user tokens authorize access, and audit logging records all activity.

43.12.1 Application Authentication

• X.509 certificates identify applications
• Certificate exchange during connection establishment
• Trust lists managed by administrators

43.12.2 Message Security

• Sign: Detect tampering (HMAC-SHA256)
• Sign and encrypt: Protect confidentiality (AES-256)

43.12.3 User Authentication

• Username/password
• X.509 user certificates
• Kerberos tokens
• SAML tokens

43.12.4 Audit Logging

• All security events logged
• Connection attempts, authentication failures
• Read/write operations on critical data

43.12.5 Security Policies

• None: Signing = No, Encryption = No. Use only for isolated testing.
• Basic128Rsa15: Signing = Yes, Encryption = Yes. Legacy compatibility only; avoid for new deployments.
• Basic256Sha256: Signing = Yes, Encryption = Yes. Widely supported, but verify whether it remains approved by the site security policy.
• Aes256-Sha256-RsaPss: Signing = Yes, Encryption = Yes. Prefer for new critical deployments when both endpoints support it and latency tests pass.

Security Best Practice

Never use Security Policy “None” in production environments. This setting disables all authentication and encryption, exposing industrial systems to unauthorized access and data manipulation. Even in development environments, testing with security enabled helps identify integration issues early.

43.12.6 OPC-UA Security Policy Comparison

Compare security policies to understand the tradeoffs between performance and protection level.

viewof selectedPolicy = Inputs.select(
  ["None", "Basic128Rsa15", "Basic256Sha256", "Aes256-Sha256-RsaPss"],
  {
    label: "Select Security Policy",
    value: "Basic256Sha256"
  }
)

viewof messageSize = Inputs.range([64, 2048], {
  value: 256,
  step: 64,
  label: "Message size (bytes)"
})

viewof messagesPerSec = Inputs.range([1, 1000], {
  value: 100,
  step: 10,
  label: "Messages per second"
})

policyData = ({
  "None": {
    encryption: "None",
    signing: "None",
    keySize: 0,
    overhead: 0,
    cpuFactor: 1.0,
    security: 0,
    color: "#E74C3C",
    recommendation: "Only isolated lab testing. Do not use on plant or enterprise networks.",
    compliance: "No production assurance; no signing, encryption, or endpoint identity."
  },
  "Basic128Rsa15": {
    encryption: "AES-128-CBC",
    signing: "HMAC-SHA1",
    keySize: 1024,
    overhead: 48,
    cpuFactor: 1.15,
    security: 40,
    color: "#E67E22",
    recommendation: "Legacy exception only. Document scope, owner, and replacement path.",
    compliance: "Compatibility profile; review against current site policy before use."
  },
  "Basic256Sha256": {
    encryption: "AES-256-CBC",
    signing: "HMAC-SHA256",
    keySize: 2048,
    overhead: 64,
    cpuFactor: 1.25,
    security: 75,
    color: "#16A085",
    recommendation: "Commonly supported baseline when site policy permits it.",
    compliance: "Policy selection alone is not compliance; roles, trust lists, audit, and change control still matter."
  },
  "Aes256-Sha256-RsaPss": {
    encryption: "AES-256-CBC",
    signing: "HMAC-SHA256",
    keySize: 4096,
    overhead: 80,
    cpuFactor: 1.40,
    security: 100,
    color: "#2C3E50",
    recommendation: "Prefer for new critical systems when endpoint support and timing tests are acceptable.",
    compliance: "Stronger cryptographic profile; still requires lifecycle, authorization, and audit evidence."
  }
})

policy = policyData[selectedPolicy]

// Calculate performance impact
baseProcessingTime = messageSize * messagesPerSec * 0.001  // microseconds
secureProcessingTime = baseProcessingTime * policy.cpuFactor
performanceOverhead = ((secureProcessingTime - baseProcessingTime) / baseProcessingTime) * 100

// Calculate bandwidth overhead
baseBandwidth = (messageSize * messagesPerSec * 8) / (1024 * 1024)  // Mbps
secureBandwidth = ((messageSize + policy.overhead) * messagesPerSec * 8) / (1024 * 1024)  // Mbps
bandwidthOverhead = ((secureBandwidth - baseBandwidth) / baseBandwidth) * 100

html`<div style="background: #f8f9fa; border-left: 4px solid ${policy.color}; padding: 20px; margin: 20px 0; border-radius: 4px; font-family: Arial, sans-serif;">
  <h4 style="margin: 0 0 15px 0; color: ${policy.color}; font-size: 18px;">${selectedPolicy}</h4>
  
  <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 15px; margin-bottom: 15px;">
    <div style="background: white; padding: 12px; border-radius: 4px;">
      <div style="font-size: 11px; color: #7F8C8D; text-transform: uppercase;">Encryption</div>
      <div style="font-size: 16px; font-weight: bold; color: #2C3E50;">${policy.encryption}</div>
    </div>
    <div style="background: white; padding: 12px; border-radius: 4px;">
      <div style="font-size: 11px; color: #7F8C8D; text-transform: uppercase;">Signing</div>
      <div style="font-size: 16px; font-weight: bold; color: #2C3E50;">${policy.signing}</div>
    </div>
    <div style="background: white; padding: 12px; border-radius: 4px;">
      <div style="font-size: 11px; color: #7F8C8D; text-transform: uppercase;">RSA Key Size</div>
      <div style="font-size: 16px; font-weight: bold; color: #2C3E50;">${policy.keySize || 'N/A'} bits</div>
    </div>
    <div style="background: white; padding: 12px; border-radius: 4px;">
      <div style="font-size: 11px; color: #7F8C8D; text-transform: uppercase;">Message Overhead</div>
      <div style="font-size: 16px; font-weight: bold; color: #2C3E50;">${policy.overhead} bytes</div>
    </div>
  </div>

  <div style="background: white; padding: 15px; border-radius: 4px; margin-bottom: 15px;">
    <div style="font-size: 12px; color: #7F8C8D; margin-bottom: 10px;">Relative Protection Score</div>
    <div style="background: #ecf0f1; height: 24px; border-radius: 12px; overflow: hidden; position: relative;">
      <div style="background: ${policy.color}; width: ${policy.security}%; height: 100%; border-radius: 12px; transition: width 0.3s;"></div>
      <div style="position: absolute; top: 0; left: 0; right: 0; bottom: 0; display: flex; align-items: center; justify-content: center; font-weight: bold; color: white; text-shadow: 0 1px 2px rgba(0,0,0,0.3); font-size: 12px;">${policy.security}%</div>
    </div>
  </div>

  <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 15px; margin-bottom: 15px;">
    <div style="background: white; padding: 12px; border-radius: 4px; text-align: center;">
      <div style="font-size: 11px; color: #7F8C8D; text-transform: uppercase;">CPU Overhead</div>
      <div style="font-size: 20px; font-weight: bold; color: #E67E22;">+${performanceOverhead.toFixed(1)}%</div>
      <div style="font-size: 11px; color: #7F8C8D; margin-top: 4px;">${secureProcessingTime.toFixed(2)} μs</div>
    </div>
    <div style="background: white; padding: 12px; border-radius: 4px; text-align: center;">
      <div style="font-size: 11px; color: #7F8C8D; text-transform: uppercase;">Bandwidth Overhead</div>
      <div style="font-size: 20px; font-weight: bold; color: #E67E22;">+${bandwidthOverhead.toFixed(1)}%</div>
      <div style="font-size: 11px; color: #7F8C8D; margin-top: 4px;">${secureBandwidth.toFixed(2)} Mbps</div>
    </div>
  </div>

  <div style="background: ${policy.security < 50 ? '#FADBD8' : policy.security < 75 ? '#FCF3CF' : '#D5F4E6'}; padding: 12px; border-radius: 4px; margin-bottom: 10px;">
    <div style="font-weight: bold; margin-bottom: 5px; color: #2C3E50;">Recommendation:</div>
    <div style="color: #2C3E50; font-size: 14px;">${policy.recommendation}</div>
  </div>

  <div style="background: white; padding: 12px; border-radius: 4px; border: 1px solid #E8E8E8;">
    <div style="font-weight: bold; margin-bottom: 5px; color: #2C3E50; font-size: 12px;">Assurance Note:</div>
    <div style="color: #7F8C8D; font-size: 13px;">${policy.compliance}</div>
  </div>
</div>`

Security Policy Selection Guidelines

For critical infrastructure (power plants, pharmaceuticals, water treatment): use the strongest site-approved security policy that both endpoints support, then validate timing and recovery behavior on representative hardware.

For standard industrial applications (manufacturing, logistics): prefer policies with signing, encryption, managed application certificates, named user identities, and tested trust-list operations.

Avoid Basic128Rsa15 unless a legacy device forces a time-bounded exception with compensating controls and an owner.

Never use “None” in any production environment. Measure the overhead of secure modes instead of assuming the insecure mode is operationally necessary.

Checkpoint: Security Baseline

You now know:

• Security Policy None is for isolated testing, not production.
• Basic256Sha256 is a common supported baseline; Aes256-Sha256-RsaPss is the stronger target when endpoints and timing support it.
• Release evidence needs application certificates, user identity, trust-list ownership, authorization roles, and audit logging, not only encryption enabled.

43.13 Companion Specifications

OPC-UA foundation provides base specifications, but industry-specific companion specifications define standardized information models:

Key companion specifications:

• OPC UA for Machinery: General manufacturing baseline machine model.
• PackML: Packaging state machines and production counters.
• EUROMAP: Plastics and rubber machine integration.
• MTConnect: CNC and machining-center data models.
• ISA-95: Enterprise integration between MES and ERP layers.
• PLCopen: Motion-control coordination and reusable machine logic.

Benefits of companion specifications:

• Plug-and-play: Machines from different vendors expose same interface
• Reduced integration: No custom mapping per vendor
• Best practices: Industry consensus on data organization
• Certification: Conformance testing ensures interoperability

OPC-UA companion model review

Figure 43.6: Companion specifications reduce custom semantics only when teams record model versions, tests, local extensions, and the client contract that downstream systems rely on.

43.14 Implementation Considerations

43.14.1 Embedded vs. Server-Class

Embedded OPC-UA (PLCs, gateways):

• Limited resources (MB of RAM, MHz processors)
• Use nano or micro profiles
• Subset of features (no complex subscriptions)
• Focus on reliability over features

Server-class OPC-UA (historians, MES):

• Full feature support
• High-performance subscriptions
• Complex information models
• Integration with enterprise systems

43.14.2 Performance Tuning

Subscription parameters:

• Publishing interval: How often server checks for changes (100ms-5s typical)
• Sampling interval: How often server reads underlying value (can be faster than publishing)
• Queue size: How many changes to buffer between publications
• Lifetime count: How many publishing intervals before subscription expires

Optimization strategies:

1. Batch reads: Read multiple nodes in single request
2. Indexed range: For arrays, read only needed elements
3. Dead-band filtering: Only report changes exceeding threshold
4. Aggregated subscriptions: Combine related nodes

43.14.3 OPC UA Subscription Performance

Use this interactive calculator to understand how subscription parameters affect bandwidth and data volume in your OPC-UA deployment.

viewof numVariables = Inputs.range([100, 10000], {
  value: 2000,
  step: 100,
  label: "Number of variables"
})

viewof publishingInterval = Inputs.range([50, 5000], {
  value: 100,
  step: 50,
  label: "Publishing interval (ms)"
})

viewof bytesPerNotification = Inputs.range([16, 128], {
  value: 32,
  step: 8,
  label: "Bytes per notification"
})

viewof deadbandReduction = Inputs.range([0, 95], {
  value: 75,
  step: 5,
  label: "Dead-band filtering reduction (%)"
})

viewof batchSize = Inputs.range([1, 50], {
  value: 10,
  step: 1,
  label: "Variables per batched message"
})

baseNotificationsPerSec = numVariables / (publishingInterval / 1000)
baseBytesPerSec = baseNotificationsPerSec * bytesPerNotification
baseGBPerDay = (baseBytesPerSec * 86400) / (1024 * 1024 * 1024)

// After dead-band filtering
filteredNotificationsPerSec = baseNotificationsPerSec * (1 - deadbandReduction / 100)
filteredBytesPerSec = filteredNotificationsPerSec * bytesPerNotification
filteredGBPerDay = (filteredBytesPerSec * 86400) / (1024 * 1024 * 1024)

// Message overhead (24 bytes per message header)
messageOverhead = 24
variablesPerMessage = batchSize
bytesPerVariableWithOverhead = bytesPerNotification + (messageOverhead / variablesPerMessage)

// After batching
batchedBytesPerSec = filteredNotificationsPerSec * bytesPerVariableWithOverhead
batchedGBPerDay = (batchedBytesPerSec * 86400) / (1024 * 1024 * 1024)

// Savings
bandwidthSavings = ((baseGBPerDay - batchedGBPerDay) / baseGBPerDay) * 100

html`<div style="background: #f8f9fa; border-left: 4px solid #16A085; padding: 15px; margin: 20px 0; border-radius: 4px; font-family: Arial, sans-serif; overflow-x: auto;">
  <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 20px; margin-bottom: 15px;">
    <div style="background: white; padding: 15px; border-radius: 4px; box-shadow: 0 2px 4px rgba(0,0,0,0.1);">
      <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase; margin-bottom: 5px;">Base Rate (Unoptimized)</div>
      <div style="font-size: 24px; font-weight: bold; color: #E74C3C;">${baseNotificationsPerSec.toFixed(0)} notifications/sec</div>
      <div style="font-size: 14px; color: #2C3E50; margin-top: 5px;">${baseGBPerDay.toFixed(1)} GB/day</div>
    </div>
    <div style="background: white; padding: 15px; border-radius: 4px; box-shadow: 0 2px 4px rgba(0,0,0,0.1);">
      <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase; margin-bottom: 5px;">After Dead-band</div>
      <div style="font-size: 24px; font-weight: bold; color: #E67E22;">${filteredNotificationsPerSec.toFixed(0)} notifications/sec</div>
      <div style="font-size: 14px; color: #2C3E50; margin-top: 5px;">${filteredGBPerDay.toFixed(1)} GB/day</div>
    </div>
    <div style="background: white; padding: 15px; border-radius: 4px; box-shadow: 0 2px 4px rgba(0,0,0,0.1);">
      <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase; margin-bottom: 5px;">Fully Optimized</div>
      <div style="font-size: 24px; font-weight: bold; color: #16A085;">${filteredNotificationsPerSec.toFixed(0)} notifications/sec</div>
      <div style="font-size: 14px; color: #2C3E50; margin-top: 5px;">${batchedGBPerDay.toFixed(1)} GB/day</div>
    </div>
  </div>
  <div style="background: white; padding: 15px; border-radius: 4px; box-shadow: 0 2px 4px rgba(0,0,0,0.1); text-align: center;">
    <div style="font-size: 14px; color: #7F8C8D; margin-bottom: 5px;">Total Bandwidth Savings</div>
    <div style="font-size: 32px; font-weight: bold; color: #16A085;">${bandwidthSavings.toFixed(1)}%</div>
    <div style="font-size: 14px; color: #2C3E50; margin-top: 5px;">${(baseGBPerDay - batchedGBPerDay).toFixed(1)} GB/day reduction</div>
  </div>
  <div style="margin-top: 15px; padding: 10px; background: #E8F8F5; border-radius: 4px; font-size: 13px; color: #2C3E50;">
    <strong>Optimization Breakdown:</strong><br/>
    • Dead-band filtering reduces notifications by ${deadbandReduction}% (${(baseGBPerDay - filteredGBPerDay).toFixed(1)} GB/day saved)<br/>
    • Batching ${batchSize} variables/message reduces overhead from ${messageOverhead} to ${(messageOverhead / batchSize).toFixed(1)} bytes/variable<br/>
    • Final rate: ${(batchedBytesPerSec / 1024).toFixed(1)} KB/sec average bandwidth
  </div>
</div>`

Interpretation Guide

Dead-band filtering eliminates noise by only reporting changes exceeding a threshold (e.g., temperature \(> 0.5°C\) change). For process variables that fluctuate within tolerance, this can reduce notifications by 70-90% with no data loss.

Batching aggregates multiple variable updates into single messages, reducing per-message overhead. Instead of 24 bytes overhead per variable, batching 10 variables means \(24/10 = 2.4\) bytes overhead each.

Typical use: Treat the calculator as a sizing aid, then validate the chosen dead-band and queue settings with actual process data so significant changes are not suppressed.

43.14.4 High Availability

Redundancy patterns:

• Server redundancy: Multiple servers with same address space
• Client failover: Automatic reconnection to backup server
• Network redundancy: Dual Ethernet paths

Session recovery:

• Transfer subscriptions: Move subscriptions to backup server
• Sequence numbers: Detect and recover from lost notifications
• Secure channel renewal: Automatic key rotation

43.15 OPC-UA in Practice

43.15.1 Typical Deployment Architecture

ISA-95 automation pyramid with OPC UA

Figure 43.7: OPC-UA often sits between real-time OT systems and operations or enterprise consumers, so each ISA-95 level needs an explicit interaction pattern and boundary rule.

A typical OPC-UA deployment spans five levels: field devices communicate via native industrial protocols, edge gateways aggregate data as OPC-UA servers, SCADA systems consume data as OPC-UA clients, cloud platforms receive pub-sub data over MQTT, and enterprise applications access analytics via REST APIs.

43.15.2 Common Integration Patterns

Pattern 1: PLC to Cloud

1. PLC runs embedded OPC-UA server
2. Edge gateway subscribes to PLC data
3. Gateway publishes to MQTT broker
4. Cloud platform consumes MQTT messages

Pattern 2: Multi-vendor Integration

1. Each vendor’s equipment exposes OPC-UA server
2. Central OPC-UA aggregator collects from all servers
3. SCADA connects to single aggregator endpoint
4. Unified namespace across all equipment

Pattern 3: Legacy Integration

1. Protocol gateway converts Modbus/PROFIBUS to OPC-UA
2. Gateway exposes standardized information model
3. Modern applications connect via OPC-UA
4. Legacy equipment remains unchanged

43.15.3 OPC-UA Deployment ROI Calculator

Explore an assumption-driven cost model for moving from custom point-to-point integration to an OPC-UA integration layer. The defaults are planning placeholders, not vendor quotes or guaranteed savings; replace them with site estimates before using the result.

viewof numDevices = Inputs.range([5, 100], {
  value: 30,
  step: 5,
  label: "Number of devices to integrate"
})

viewof customIntegrationHours = Inputs.range([10, 50], {
  value: 20,
  step: 5,
  label: "Hours to integrate each device (custom)"
})

viewof opcuaIntegrationHours = Inputs.range([1, 10], {
  value: 4,
  step: 1,
  label: "Hours to integrate each device (OPC-UA)"
})

viewof hourlyRate = Inputs.range([80, 200], {
  value: 120,
  step: 10,
  label: "Integration labor rate ($/hour)"
})

viewof gatewayCount = Inputs.range([0, 10], {
  value: 2,
  step: 1,
  label: "Number of protocol gateways needed"
})

viewof gatewayCost = Inputs.range([2000, 10000], {
  value: 4800,
  step: 500,
  label: "Cost per gateway ($)"
})

viewof edgeAggregatorCost = Inputs.range([0, 20000], {
  value: 7500,
  step: 500,
  label: "Edge aggregator software cost ($)"
})

viewof annualMaintenanceCustom = Inputs.range([10000, 50000], {
  value: 25000,
  step: 5000,
  label: "Annual maintenance cost - custom ($)"
})

viewof annualMaintenanceOpcua = Inputs.range([1000, 10000], {
  value: 3500,
  step: 500,
  label: "Annual maintenance cost - OPC-UA ($)"
})

customIntegrationCost = numDevices * customIntegrationHours * hourlyRate
customYear1 = customIntegrationCost + annualMaintenanceCustom
custom3Year = customIntegrationCost + (3 * annualMaintenanceCustom)
custom5Year = customIntegrationCost + (5 * annualMaintenanceCustom)

// OPC-UA costs
opcuaHardwareCost = (gatewayCount * gatewayCost) + edgeAggregatorCost
opcuaIntegrationCost = numDevices * opcuaIntegrationHours * hourlyRate
opcuaYear1 = opcuaHardwareCost + opcuaIntegrationCost + annualMaintenanceOpcua
opcua3Year = opcuaHardwareCost + opcuaIntegrationCost + (3 * annualMaintenanceOpcua)
opcua5Year = opcuaHardwareCost + opcuaIntegrationCost + (5 * annualMaintenanceOpcua)

// Savings
year1Savings = customYear1 - opcuaYear1
savings3Year = custom3Year - opcua3Year
savings5Year = custom5Year - opcua5Year

// Break-even time (months)
monthlyMaintenanceDiff = (annualMaintenanceCustom - annualMaintenanceOpcua) / 12
initialInvestmentDiff = opcuaYear1 - customYear1
breakEvenMonths = initialInvestmentDiff > 0 ? initialInvestmentDiff / monthlyMaintenanceDiff : 0

// ROI percentage
roi3Year = ((savings3Year) / opcua3Year) * 100
roi5Year = ((savings5Year) / opcua5Year) * 100

html`<div style="background: #f8f9fa; border-left: 4px solid #16A085; padding: 20px; margin: 20px 0; border-radius: 4px; font-family: Arial, sans-serif;">
  <h4 style="margin: 0 0 20px 0; color: #2C3E50; font-size: 18px;">Cost Comparison: Custom vs. OPC-UA</h4>
  
  <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 20px; margin-bottom: 20px;">
    <div style="background: white; padding: 15px; border-radius: 4px; box-shadow: 0 2px 4px rgba(0,0,0,0.1); border-top: 3px solid #E74C3C;">
      <div style="font-size: 14px; color: #7F8C8D; margin-bottom: 10px; font-weight: bold;">Custom Point-to-Point</div>
      <div style="margin-bottom: 10px;">
        <div style="font-size: 11px; color: #7F8C8D;">Initial Integration</div>
        <div style="font-size: 18px; font-weight: bold; color: #2C3E50;">$${customIntegrationCost.toLocaleString()}</div>
        <div style="font-size: 11px; color: #7F8C8D;">${numDevices} devices × ${customIntegrationHours}h × $${hourlyRate}/h</div>
      </div>
      <div style="margin-bottom: 10px;">
        <div style="font-size: 11px; color: #7F8C8D;">Year 1 Total</div>
        <div style="font-size: 20px; font-weight: bold; color: #E74C3C;">$${customYear1.toLocaleString()}</div>
      </div>
      <div style="margin-bottom: 10px;">
        <div style="font-size: 11px; color: #7F8C8D;">3-Year Total</div>
        <div style="font-size: 18px; font-weight: bold; color: #2C3E50;">$${custom3Year.toLocaleString()}</div>
      </div>
      <div>
        <div style="font-size: 11px; color: #7F8C8D;">5-Year Total</div>
        <div style="font-size: 18px; font-weight: bold; color: #2C3E50;">$${custom5Year.toLocaleString()}</div>
      </div>
    </div>

    <div style="background: white; padding: 15px; border-radius: 4px; box-shadow: 0 2px 4px rgba(0,0,0,0.1); border-top: 3px solid #16A085;">
      <div style="font-size: 14px; color: #7F8C8D; margin-bottom: 10px; font-weight: bold;">OPC-UA Unified</div>
      <div style="margin-bottom: 10px;">
        <div style="font-size: 11px; color: #7F8C8D;">Hardware + Integration</div>
        <div style="font-size: 18px; font-weight: bold; color: #2C3E50;">$${(opcuaHardwareCost + opcuaIntegrationCost).toLocaleString()}</div>
        <div style="font-size: 11px; color: #7F8C8D;">Gateways: $${(gatewayCount * gatewayCost).toLocaleString()} | Labor: $${opcuaIntegrationCost.toLocaleString()}</div>
      </div>
      <div style="margin-bottom: 10px;">
        <div style="font-size: 11px; color: #7F8C8D;">Year 1 Total</div>
        <div style="font-size: 20px; font-weight: bold; color: #16A085;">$${opcuaYear1.toLocaleString()}</div>
      </div>
      <div style="margin-bottom: 10px;">
        <div style="font-size: 11px; color: #7F8C8D;">3-Year Total</div>
        <div style="font-size: 18px; font-weight: bold; color: #2C3E50;">$${opcua3Year.toLocaleString()}</div>
      </div>
      <div>
        <div style="font-size: 11px; color: #7F8C8D;">5-Year Total</div>
        <div style="font-size: 18px; font-weight: bold; color: #2C3E50;">$${opcua5Year.toLocaleString()}</div>
      </div>
    </div>
  </div>

  <div style="background: linear-gradient(135deg, #D5F4E6 0%, #E8F8F5 100%); padding: 20px; border-radius: 8px; margin-bottom: 15px; box-shadow: 0 2px 4px rgba(0,0,0,0.1); overflow-x: auto;">
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); gap: 15px; text-align: center;">
      <div>
        <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase; margin-bottom: 5px;">Year 1 Savings</div>
        <div style="font-size: 28px; font-weight: bold; color: ${year1Savings >= 0 ? '#16A085' : '#E74C3C'};">${year1Savings >= 0 ? '+' : ''}$${year1Savings.toLocaleString()}</div>
        <div style="font-size: 11px; color: #7F8C8D;">${year1Savings >= 0 ? 'OPC-UA cheaper' : 'Higher initial cost'}</div>
      </div>
      <div>
        <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase; margin-bottom: 5px;">3-Year Savings</div>
        <div style="font-size: 28px; font-weight: bold; color: #16A085;">+$${savings3Year.toLocaleString()}</div>
        <div style="font-size: 11px; color: #7F8C8D;">ROI: ${roi3Year.toFixed(0)}%</div>
      </div>
      <div>
        <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase; margin-bottom: 5px;">5-Year Savings</div>
        <div style="font-size: 28px; font-weight: bold; color: #16A085;">+$${savings5Year.toLocaleString()}</div>
        <div style="font-size: 11px; color: #7F8C8D;">ROI: ${roi5Year.toFixed(0)}%</div>
      </div>
    </div>
  </div>

  <div style="background: white; padding: 15px; border-radius: 4px; box-shadow: 0 2px 4px rgba(0,0,0,0.1);">
    <div style="display: flex; flex-wrap: wrap; gap: 16px; justify-content: space-between; align-items: flex-start;">
      <div style="min-width: 180px; flex: 1 1 180px;">
        <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase;">Break-Even Point</div>
        <div style="font-size: 24px; font-weight: bold; color: #2C3E50;">
          ${breakEvenMonths > 0 ? breakEvenMonths.toFixed(1) + ' months' : 'Immediate'}
        </div>
      </div>
      <div style="min-width: 180px; flex: 1 1 180px; text-align: left;">
        <div style="font-size: 12px; color: #7F8C8D; text-transform: uppercase;">Monthly Maintenance Savings</div>
        <div style="font-size: 20px; font-weight: bold; color: #16A085;">$${monthlyMaintenanceDiff.toLocaleString()}/mo</div>
      </div>
    </div>
  </div>

  <div style="margin-top: 15px; padding: 12px; background: #FEF5E7; border-left: 3px solid #E67E22; border-radius: 4px; font-size: 13px; color: #2C3E50;">
    <strong>Planning Insight:</strong> In this model, OPC-UA ${year1Savings >= 0 ? 'reduces first-year cost' : 'starts with higher first-year cost'} because integration hours and maintenance assumptions differ. Treat the ${((savings3Year/custom3Year)*100).toFixed(0)}% three-year reduction as a scenario output to validate, not a benchmark.
  </div>
</div>`

Understanding the ROI

The calculator shows how assumptions can change an OPC-UA business case:

Year 1: May have higher costs due to gateway/software purchases, but reduced integration labor often compensates.

Year 2-3: Lower annual maintenance can drive positive ROI if the model, gateway, and certificate lifecycle are actually easier to operate than the custom alternative.

Year 4-5: Savings may accelerate when standardized onboarding reduces the effort needed to add new equipment.

Real-world factors not modeled: outage windows, validation effort, vendor support, license terms, cybersecurity review, and the cost of maintaining namespace and certificate ownership over time.

43.15.4 OPC UA Bottling Plant Migration

Scenario: A beverage company operates a bottling line with native PROFINET PLCs, EtherCAT motion equipment, inspection cameras, and legacy Modbus RTU conveyor controllers. Management wants OEE dashboards and maintenance analytics without replacing functioning equipment.

Step 1: Inventory and protocol mapping

• Native OPC-UA sources: Identify controllers that already expose a supported OPC-UA server and document their endpoint policies, namespaces, and writable nodes.
• Gateway-required sources: Place legacy serial and vendor-specific Ethernet devices behind gateways that add asset names, units, quality codes, timestamps, and references.
• Consumer contracts: Separate SCADA/HMI operational clients from historian, MES, and cloud analytics consumers.

Step 2: Architecture design

• Direct OPC-UA: Let SCADA connect to native servers or an aggregator for browse, read, subscriptions, and approved writes.
• Protocol gateways: Bridge brownfield sources into a unified namespace without flattening everything into anonymous tags.
• Cloud connectivity: Publish selected read-only datasets through an edge or DMZ broker so cloud systems do not hold direct control-network sessions.

Step 3: Subscription tuning

Not all variables need the same update rate. Categorizing by purpose keeps significant changes visible without turning the historian into a packet sink:

• Safety and interlock evidence: Preserve every meaningful transition and test queue overflow behavior.
• Process control context: Use bounded sampling and queue settings that match the control cell’s diagnostic need.
• Quality metrics: Apply dead-band only where the process owner confirms small changes are noise.
• Dashboards and OEE: Publish slower aggregates when operators do not need every raw sample.

Result: The migration is ready for release only when reviewers can trace one value from source controller or gateway, through namespace and security policy, into the historian or dashboard, while preserving unit, quality, timestamp, owner, and allowed write behavior.

Checkpoint: Deployment Evidence

You now know:

• Subscription tuning starts with publishing interval, sampling interval, queue size, lifetime count, batching, and dead-band rules.
• The calculator’s defaults make the scale concrete: 2,000 variables at 100 ms can overwhelm a historian unless queueing and filtering are engineered.
• A brownfield release is not complete until one value can be traced from native OPC UA or gateway source through namespace, security policy, consumer, and decision.

Concept Relationships: OPC-UA Standard

• OPC-UA -> ISA-95 Levels 0-3: bridges the control layer (PLC) to the operations layer (MES/ERP).
• OPC-UA -> Industrial Protocols: replaces proprietary Modbus and PROFINET links with a vendor-neutral standard.
• Client-Server -> SCADA Systems: supports direct request-response access for HMI and configuration tools.
• Pub-Sub -> MQTT/AMQP: provides a decoupled pattern for cloud connectivity and analytics.

Cross-module connection: Real-Time Requirements and ISA-95 explains timing constraints that determine when to use OPC-UA client-server vs. pub-sub patterns.

Interactive Quiz: Match OPC-UA Concepts

Quiz: OPC UA Deployment

Common Pitfalls

Flat Tags Are Not a Model

An OPC-UA endpoint that exposes thousands of PLC tags without units, quality, equipment hierarchy, or ownership is connected but not integrated. Model assets, variables, methods, and references so clients can understand the operational meaning of each value.

Certificate Trust Matters

Trust lists, certificate renewal, user identity, role mapping, and endpoint policy need owners before release. If nobody owns certificate expiry or rejected-client handling, the first maintenance window can become an outage.

Keep Cloud Off Control Paths

Cloud dashboards and analytics should receive selected read-only datasets through an edge or DMZ boundary. Keep operational write methods inside the approved OT path unless authorization, safety review, and recovery behavior are engineered for remote writes.

Label the Diagram

Code Challenge

43.16 Summary

OPC-UA has emerged as the definitive standard for industrial interoperability. Here are the key takeaways from this chapter:

Key Takeaways:

1. Platform Independence: OPC-UA works across operating systems, hardware platforms, and programming languages, eliminating vendor lock-in. From embedded PLCs with megabytes of RAM to enterprise cloud servers, OPC-UA scales across the entire automation hierarchy.

2. Semantic Data Modeling: The self-describing, object-oriented information model (nodes, references, attributes) enables clients to discover and understand device capabilities with less vendor-specific mapping.

3. Built-in Security: Unlike legacy protocols (Modbus, PROFIBUS) that have no native security, OPC-UA provides layered defense: application certificates, message signing and encryption, multiple user authentication methods, and audit logging that supports controlled operations.

4. Dual Communication Patterns: Client-server mode supports traditional SCADA and HMI use cases requiring direct request-response interaction. Pub-sub mode (over MQTT/AMQP) enables scalable, firewall-friendly cloud connectivity for analytics and monitoring.

5. Companion Specifications: Industry-specific extensions such as PackML, EUROMAP, MTConnect, and ISA-95 provide standardized information models that reduce custom semantic mapping when the model version and local extensions are documented.

6. Legacy Integration: Protocol gateways bridge legacy Modbus, PROFIBUS, PROFINET, and vendor-driver devices into OPC-UA, allowing modernization without replacing functioning equipment.

Critical Design Decision

When designing an OPC-UA deployment, always use client-server for control and direct device interaction (SCADA, HMI), and pub-sub over MQTT for cloud connectivity and analytics. Never use Security Policy “None” in production. Start with companion specifications for your industry before creating custom information models.

43.17 See Also

• Industrial Protocols — Comparison of Modbus, PROFINET, and EtherCAT to understand when OPC-UA bridges legacy systems
• Predictive Maintenance — OPC-UA data collection enables ML-based failure prediction in IIoT
• Real-Time Requirements — Timing constraints across ISA-95 levels determine client-server vs pub-sub choice

In 60 Seconds

OPC-UA turns industrial values into governed information models: clients browse nodes, use secured sessions, preserve quality and timestamp evidence, and publish only approved data across IT/OT boundaries.

43.18 What’s Next

• Next: Real-Time Requirements and ISA-95 for timing constraints and automation hierarchy.
• Related: Predictive Maintenance for condition monitoring use cases.
• Related: Industrial Protocols for Modbus, PROFINET, and EtherCAT comparison.
• Index: Industry 4.0 Fundamentals for the full IIoT chapter sequence.