OPC UA enables industrial equipment from different vendors to exchange information seamlessly through a service-oriented architecture. Rather than requiring detailed knowledge of each device's internal workings, OPC UA defines standardized services that clients invoke to read data, write values, browse server structure, and call methods. This tutorial explains how OPC UA client-server communication works, from service requests to responses.

Understanding OPC UA communication architecture is essential for developers building industrial applications and system integrators connecting equipment from multiple vendors.

‍

‍

Service-Oriented Architecture in Manufacturing

‍

Consider a manufacturing organization bringing together many components to produce finished products: factory floor devices, machines, robots, SCADA systems, MES, and ERP systems. For these components to work together successfully, they must exchange information and instructions easily.

‍

Components as Service Providers

‍

Each component in a factory provides a service—whether a robotic arm stacking goods onto pallets or MES tracking production activities. The internal logic of how the robotic arm performs its tasks doesn't need to be understood in detail by other components. Those internal functions can be abstracted away.

What should be exposed instead is a list of functions or services the robotic arm can perform and instructions for how other components invoke those services. This communication architecture that coordinates operations toward common goals by having participating components provide services to each other is called service-oriented architecture (SOA).

OPC UA communication is based on this service-oriented architecture.

‍

OPC UA Services for Industrial Applications

‍

OPC UA provides service-oriented architecture for industrial applications by defining abstract services:

• Read: Retrieve current values from server nodes
• Write: Update values on server nodes
• Browse: Discover the structure of server address space
• Subscribe: Monitor nodes for value changes
• Method Calls: Execute functions on the server

These services expose underlying device or equipment functionality. When industrial equipment and application vendors implement OPC UA on their products, they abstract internal workings and expose only standardized interfaces accessible through OPC UA services.

This enables industrial systems from different vendors to exchange information seamlessly without understanding internal details like register addresses, proprietary commands, or vendor-specific protocols—something traditionally difficult to achieve with technologies like Modbus, PROFIBUS, or DeviceNet.

‍

Enabling Flexible Production Reconfiguration

‍

Traditional production procedures execute through hard-wired control loops: sensors provide input to controllers, which send appropriate signals to actuators. When customer requirements fall outside standard production procedures, you must stop production, reconfigure equipment, and sometimes reprogram PLCs.

OPC UA-based service-oriented architecture enables external systems to call machine methods or services to instruct them, making production reconfiguration automated, easier, and faster.

This reconfiguration interface extends to IT and business software outside the control system domain, allowing control loops to be driven by business context—a scenario often called IT/OT convergence.

‍

Client-Server Interaction Mechanism

‍

An OPC UA server provides methods or services that OPC UA clients call when accessing data or sending instructions. To facilitate this interaction, OPC UA provides mechanisms enabling clients to:

1. Discover OPC UA servers locally or on networks
2. Interrogate servers to find what services they offer
3. Connect to servers
4. Use their services
5. Disconnect when finished

This discovery and connection process happens automatically through standardized protocols, simplifying application development.

‍

Layered Architecture for Future-Proofing

‍

OPC UA's service-oriented architecture is built on different logical levels:

Service Level: All OPC UA services are abstract method descriptions defined at this level

Transport and Encoding Level: Data transportation and encoding mechanisms are defined separately

Application Interface Level: Interfacing between the OPC UA communication stack and user application code is left to programming environment and SDK developers

This separation of concerns future-proofs the OPC UA standard—it's not reliant on any single transportation mechanism. When new transport protocols emerge, OPC UA can adopt them without changing service definitions.

Technology stack developers map defined services onto transport protocols through OPC UA technology mapping, which provides flexibility in implementation choices.

‍

Request-Response Communication Model

‍

OPC UA services use request-response communication, requiring two participants:

Client: Initiates communication by sending requests

Server: Processes requests and returns responses

When a client wants to read data from a server, it sends a read request. The server processes the request and returns a response containing the requested data and operation status.

‍

Under the Hood: Communication Stack Architecture

‍

Let's examine what happens during information exchange.

‍

Both Sides Need Communication Stacks

‍

Both the device or application acting as OPC UA client and the device or application acting as OPC UA server must implement an OPC UA communication stack. Implementations exist in multiple languages:

• C
• C++
• Java
• Node.js
• .NET

As an application developer, you don't deal directly with the underlying stack. Instead, you send and receive messages via an API or SDK.

‍

Language Independence

The client and server can use different technology stacks—for example, the server might use a .NET OPC UA stack while the client uses a Node.js stack. The only requirement is that both must use the same technology for transporting messages.

This language independence is a significant advantage, allowing organizations to choose development technologies based on their expertise and requirements rather than compatibility constraints.

‍

The Communication Process Step-by-Step

‍

Step 1: Client Submits Service Request

The process begins in OPC UA user application code. The client uses an OPC UA SDK or API to submit a service request—for example, a read service request.

OPC UA doesn't specify how SDKs or APIs must interface with user application code, but ordinarily, SDKs provide methods corresponding to the specification. A read request might look like:

ReadValue(nodeId, attributeId)

‍

Step 2: Stack Encodes the Request

The OPC UA stack accepts the service request and encodes it in a message format conforming to the OPC UA specification for exchanging data on the wire. Encoding transforms the service request into a byte stream suitable for network transmission.

‍

Step 3: Request Transfer

The encoded service request is transferred to the server-side stack using a transportation mechanism common to both stacks. The transportation mechanism—whether OPC UA TCP, HTTPS, or WebSockets—is determined during the connection establishment phase.

‍

Step 4: Server Processes Request

On the receiving end, the OPC UA server:

1. Receives the service request
2. Decodes it from byte stream to structured data
3. Locates the service to execute
4. Performs the requested operation
5. Sends a response message with operation results and status

The response includes both the requested data (if successful) and a status code indicating whether the operation succeeded or failed, along with any error information.

‍

Step 5: Client Receives Response

The client's OPC UA stack receives the response, decodes it, and presents the results to the application through the SDK or API. The application can then use the retrieved data or handle any errors that occurred.

‍

Efficiency Through Batching

To reduce the number of request-response operations, OPC UA services support batching—sending multiple operations in a single request. For example, a single read request can retrieve values from multiple nodes simultaneously, reducing network overhead and improving performance.

This batching capability is particularly important in industrial environments where hundreds or thousands of data points may need regular monitoring.

‍

Service Categories

OPC UA defines services in several categories:

Discovery Services: Find available OPC UA servers on the network

Secure Channel Services: Establish encrypted communication channels

Session Services: Create and manage sessions between clients and servers

Node Management Services: Add, delete, or modify nodes in the server address space

View Services: Browse the hierarchical structure of the server's address space

Query Services: Retrieve sets of nodes meeting specific criteria

Attribute Services: Read and write node attributes like values, data types, and descriptions

Method Services: Call methods on server objects

MonitoredItem Services: Create subscriptions that notify clients of data changes

Subscription Services: Manage subscriptions and configure update rates

Each service category addresses specific communication needs, providing a comprehensive framework for industrial application development.

‍

Summary

‍

OPC UA client-server communication is built on service-oriented architecture where servers expose standardized services that clients invoke. This abstraction enables seamless information exchange between industrial equipment from different vendors without requiring knowledge of internal implementation details.

The layered architecture separates service definitions from transport mechanisms, future-proofing the standard and allowing adoption of new technologies without breaking existing applications. Request-response communication with batching support provides efficient data exchange, while comprehensive service categories cover all industrial communication requirements.

Understanding this communication model enables developers to build robust industrial applications that leverage OPC UA's interoperability benefits, creating flexible manufacturing systems that adapt easily to changing requirements.

‍