102 OPC UA: Architecture, Models, and Security

102.1 Overview

This first route builds the OPC UA architecture from information models and communication patterns through a reviewable security baseline.

This is part 1 of 2. Continue with OPC UA: Companion Models and Implementation for the second focused route.

102.2 Start With the Story

Picture two factory lines that both report a value called speed. One means motor turns per minute. The other means belt metres per second. Joining the raw tags would create a quiet but dangerous error.

OPC Unified Architecture (OPC UA) gives industrial data shared names, types, units, quality, time, and links. A protocol is an agreed set of rules for how systems exchange data. Transmission Control Protocol (TCP) provides an ordered byte stream between two endpoints. Start with the machine meaning, not the wire. Name the asset, value, unit, state, and allowed action. Then choose the exchange pattern. Keep a fast or safe control loop near the machine when a remote link cannot own it.

Use this first review path:

• Which machine fact is shared?
• What does the name mean?
• Which unit does it use?
• How fresh is the value?
• Is its quality known?
• Who may read it?
• Who may change it?
• Which certificate proves identity?
• What happens when trust fails?
• Can the local process stay safe?

OPC UA can share meaning. It cannot repair a weak source model by itself. Practitioner covers nodes, service patterns, certificates, roles, and field rollout. Under the Hood covers the full information model, security choices, subscription tuning, and companion rules. Those details refine the shared model. They do not make two unlike tags mean the same thing.

Retell one machine value. Start at the asset. Name the part. Name the value. Name the unit. Name the time. Name the quality. Name the source. Mark whether it can change. Mark who may change it. Keep those facts with the value.

Then choose the exchange. A client may ask a server. A client may watch for change. A publisher may send events. A subscriber may receive them. The pattern follows the job. Fast control may stay local. Remote systems may read a safe view. A lost link has a known effect. A stale value stays marked stale.

Then protect the route. Each system has an identity. A certificate can support that identity. Trust lists name accepted peers. User roles limit human acts. Signing can show tampering. Encryption can hide data in transit. A safe policy still needs owners. Old trust must be removed. Failed trust must stay visible.

Then keep the model alive. One team owns the names. One team owns each source. Model changes get a version. Clients can detect that version. A companion model may provide shared terms. A local extension stays documented. New machines keep the contract. Old machines keep clear adapters. Tests catch a broken meaning.

Finish at release. The consumer is named. The control limit is named. The trust owner is named. The local fallback is named. The field test is recorded. The change process is recorded. The deeper model can add detail. It cannot change the unit in secret.

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.

102.3 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

102.4 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

102.5 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.

102.6 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.

102.7 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.

The hierarchy in Figure 102.2 makes those semantics inspectable. Follow the object types, objects, variables, methods, properties, and references to see how a client discovers both a value and the operational context needed to interpret it safely. 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.

102.8 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.

102.9 Why OPC-UA?

102.10 OPC-UA Architecture

Ground opc-ua architecture with the visual at Figure 102.1. Start from OPC UA Client-Server Architecture, but keep Unified Architecture for Industrial Communication visible while evaluating opc-ua servers expose address-space nodes and service sets through secured sessions so scada, hmi, mes, and erp clients can browse, read, subscribe,.

Locate OPC UA Client-Server Architecture on Figure 102.1 before checking Unified Architecture for Industrial Communication. The visual’s third anchor, OPC UA Server, completes opc-ua servers expose address-space nodes and service sets through secured sessions so scada, hmi, mes, and erp clients can browse, read, subscribe,. Carry OPC UA Client-Server Architecture into opc-ua architecture; use OPC UA Server as its limiting condition.

102.11 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:

The visual evidence for information model sits in Figure 102.2. Find OPC-UA Information Model Hierarchy beside Self-describing object-oriented data model before interpreting the information model gives clients more than a value: it exposes type, unit, timestamp, quality, method, property, and relationship context.

Compare OPC-UA Information Model Hierarchy with Self-describing object-oriented data model inside the visual at Figure 102.2. Next find Object Types, which completes the scope of the information model gives clients more than a value: it exposes type, unit, timestamp, quality, method, property, and relationship context. The decision in information model must preserve that labelled boundary. This self-describing model means clients can discover capabilities without prior knowledge of the device.

102.12 Communication Patterns

To test communication patterns, open the diagram in Figure 102.3. OPC-UA Client-Server Communication supplies one named condition; Client Application supplies the necessary comparison for client-server communication separates discovery, read/write access, subscriptions, notifications, and secure-channel handling.

At OPC-UA Client-Server Communication in Figure 102.3, compare the diagram with Client Application; then locate Session Manager. That labelled check bounds client-server communication separates discovery, read/write access, subscriptions, notifications, and secure-channel handling. For communication patterns, retain Session Manager as evidence for the resulting choice. 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.

102.13 Security Features

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

The next claim about security features depends on Figure 102.4. Its diagram makes Trust Record Before Release and Trust Authority explicit within opc-ua security needs certificate ownership, trust-list management, user identity, authorization roles, and endpoint policy evidence, not only a.

Trace the visual from Trust Record Before Release to Trust Authority in Figure 102.4; verify issuer, revocation, renewal before concluding. Together those labels make opc-ua security needs certificate ownership, trust-list management, user identity, authorization roles, and endpoint policy evidence, not only a testable. Apply their boundary when working through security features. 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.

102.14 Continue to Part 2

Continue with OPC UA: Companion Models and Implementation.