OPC UA services are the operations that make everything happen. When a client reads a temperature value, subscribes to alarms, calls a method on a remote machine, or browses a server’s data structure — it’s using OPC UA services.
Services are defined in IEC 62541 Part 4. They’re abstract — meaning the standard describes what each service does and what parameters it takes, without tying it to a specific implementation technology. The actual encoding and transport are handled separately in Part 6 (Mappings).
This guide explains every OPC UA service set, what each service does, and when you’d use it in real applications.
Table of Contents
What Are OPC UA Services?
OPC UA services are standardized remote procedure calls (RPCs) that clients invoke on servers. Every interaction between a client and server happens through these services — there’s no other way to exchange data.
The service-oriented architecture follows a request/response pattern. The client sends a request with defined parameters. The server processes it and returns a response. Every request includes a RequestHeader (with authentication token, timestamp, and request handle) and every response includes a ResponseHeader (with service result and diagnostic info).
One key innovation of OPC UA is that services are unified. In OPC Classic, there were separate browse operations for DA, A&E, and HDA. In OPC UA, there’s one Browse service that works across the entire address space. One Read service reads any attribute. This unification is what makes OPC UA simpler despite being more powerful.
The Service Sets at a Glance
OPC UA organizes its services into logical groups called service sets. There are ten service sets in total.
| Service Set | Purpose | When You Use It |
|---|---|---|
| Discovery | Find servers and endpoints | Before connecting |
| SecureChannel | Establish encrypted communication | During connection setup |
| Session | Authenticate users, manage sessions | During connection setup |
| NodeManagement | Add, modify, delete nodes | Server configuration |
| View | Browse the address space | Exploring server data |
| Query | Search address space with filters | Advanced data retrieval |
| Attribute | Read and write node values | Core data access |
| Method | Call functions on the server | Remote operations |
| MonitoredItem | Watch nodes for changes | Setting up subscriptions |
| Subscription | Receive change notifications | Real-time monitoring |
The first three (Discovery, SecureChannel, Session) handle the connection lifecycle. The remaining seven handle actual data operations.
Not every server implements every service. IEC 62541 Part 7 defines profiles that specify which services a server must support. A basic Data Access server implements fewer services than a full-featured server with historical access and alarm management.
Connection Services
These three service sets establish and secure the connection before any data flows.
Discovery Service Set
Before connecting to a server, a client needs to find it and learn what it offers.
FindServers returns a list of OPC UA servers registered on a machine or network. You point it at a hostname and it tells you what’s available.
GetEndpoints returns the list of endpoints a specific server supports. Each endpoint describes a URL to connect to, a security policy (which algorithms to use), a security mode (None, Sign, or SignAndEncrypt), and a user authentication method. The client picks the endpoint that matches its requirements.
FindServersOnNetwork queries a Discovery Server for all registered servers on the local network. This is how clients find servers they don’t already know about.
RegisterServer / RegisterServer2 allow servers to register themselves with a Discovery Server so other clients can find them.
In practice, GetEndpoints is the service you’ll use most. A typical workflow: call FindServers to get the server list, then call GetEndpoints on the one you want to get its security configuration.
SecureChannel Service Set
Once the client knows which endpoint to use, it establishes an encrypted connection.
OpenSecureChannel creates a new secure channel or renews an existing one. During this call, the client and server exchange X.509 certificates, authenticate each other, negotiate the security policy, and derive shared encryption keys.
The secure channel has a security token with a limited lifetime. Before the token expires, the client must call OpenSecureChannel again to renew the keys. This periodic key rotation prevents attackers from accumulating enough encrypted traffic to crack the keys.
CloseSecureChannel terminates the secure channel when the client is done.
These services are handled by the communication stack, not the application code. Most developers never call them directly — the OPC UA SDK manages the secure channel automatically.
Session Service Set
With the secure channel in place, the client creates an application-level session.
CreateSession establishes a new session. The server returns a SessionId (used for diagnostics and audit logs) and a SessionAuthenticationToken (included in every subsequent request to prove the client owns the session).
ActivateSession associates a user identity with the session. This is where user authentication happens — the client submits a UserIdentityToken (username/password, X.509 certificate, or enterprise token) and the server validates it. Clients can call ActivateSession again to change the user identity or to migrate the session to a new secure channel.
CloseSession terminates the session and releases all resources (subscriptions, monitored items, continuation points).
Cancel cancels outstanding service requests. The server responds to cancelled requests with Bad_RequestCancelledByClient.
Key design point: sessions are independent of secure channels. If the network drops and the secure channel breaks, the session survives. The client can open a new secure channel and re-activate the same session — no data loss, no re-authentication needed.
Data Access Services
These service sets handle the core operations: reading, writing, browsing, and querying.
View Service Set
The View service set lets clients explore the address space by navigating nodes and following references.
Browse returns the list of references from one or more starting nodes. You tell it which node to start from, which direction to browse (forward, inverse, or both), and optionally which reference types to follow. It returns the referenced nodes with their NodeClass, BrowseName, DisplayName, and NodeId.
BrowseNext continues a browse operation that returned too many results to fit in a single response. The server returns a continuation point, and BrowseNext picks up where Browse left off.
TranslateBrowsePathsToNodeIds converts a browse path (like “Objects/PLC_1/Temperature”) into a NodeId. This is critical for clients that know the structure they want to access but don’t know the specific NodeIds — which change between server implementations.
RegisterNodes tells the server that the client plans to access certain nodes repeatedly (for frequent reads, writes, or method calls). The server can optimize internal resources for faster access. The counterpart UnregisterNodes releases those optimizations.
Query Service Set
While browsing walks the address space step by step, querying lets you search across it in one call.
QueryFirst submits a query with filter criteria and returns matching nodes. You can filter by NodeClass, type definition, or specific attribute values. Think of it as a database SELECT against the address space.
QueryNext retrieves the next batch of results if the query returned more data than could fit in one response.
The Query service set is powerful but not all servers implement it. Querying can be resource-intensive, especially if it requires accessing runtime data from physical devices. Some servers reject complex queries to protect performance.
Attribute Service Set
This is the workhorse of OPC UA data access. The Attribute service set reads and writes the actual values.
Read returns the values of one or more attributes from one or more nodes in a single call. The most common use is reading the Value attribute of Variable nodes — that’s how you get your temperatures, pressures, speeds, and states. But you can also read any other attribute: DisplayName, Description, DataType, AccessLevel, and so on.
Read supports historical data too. By specifying a time range, you can retrieve historical values (if the server supports Historical Access).
Write updates the values of one or more attributes. For Variable nodes, this means writing a new value — setting a setpoint, sending a command, updating a configuration parameter. The server checks the user’s authorization before allowing the write.
HistoryRead retrieves historical data or events from the server’s historian. You can request raw values, modified values, or processed values (aggregates like averages and maximums) within a specified time range.
HistoryUpdate modifies historical data — inserting new values, replacing existing ones, or deleting historical records. This is used by historian applications that need to correct or supplement historical data.
Method Service Set
Methods are callable functions exposed by objects in the address space.
Call invokes one or more methods. Each method call specifies the object that owns the method, the method’s NodeId, and the input arguments. The server executes the method and returns the output arguments and a status code.
Methods are synchronous — they run to completion and return the result. For long-running operations, OPC UA uses the Program model (defined in Part 10) which combines methods with state machines for asynchronous execution.
Real-world uses of methods: Start() and Stop() for motors, Calibrate() for instruments, ResetCounter() for production lines, SetRecipe() for process equipment, and SwitchPumps() for fluid systems.
Subscription Services
The subscription model is what makes OPC UA efficient for real-time monitoring. Instead of polling (repeatedly calling Read), clients subscribe to data and receive updates only when something changes.
MonitoredItem Service Set
Monitored items are the entities that watch nodes for changes.
CreateMonitoredItems creates one or more monitored items within a subscription. For each item, you specify the NodeId to watch, the sampling interval (how often the server checks the value), the queue size (how many notifications to buffer), and a filter (what constitutes a reportable change — like a deadband for analog values or an event filter for events).
ModifyMonitoredItems changes the parameters of existing monitored items — adjusting the sampling rate, filter, or queue size without recreating them.
SetMonitoringMode switches monitored items between three modes: Disabled (no sampling, no reporting), Sampling (server samples but doesn’t report), and Reporting (full operation — samples and sends notifications).
SetTriggering links monitored items so that one item’s notification triggers another to report. This is useful when you want one fast-changing signal to trigger the capture of related slower signals.
DeleteMonitoredItems removes monitored items from a subscription.
Subscription Service Set
Subscriptions collect notifications from monitored items and deliver them to clients.
CreateSubscription creates a new subscription with a configured publishing interval (how often the server sends notifications), a lifetime count (how many publishing intervals can pass without client activity before the server deletes the subscription), and a max keep-alive count (how many intervals with no changes before the server sends a keep-alive).
ModifySubscription adjusts subscription parameters without recreating it.
SetPublishingMode enables or disables publishing for a subscription without deleting it.
Publish is the heartbeat of the subscription model. The client sends Publish requests, and the server responds with NotificationMessages containing queued notifications. Each NotificationMessage has a sequence number. If the client detects a gap, it can request retransmission.
Republish requests retransmission of a specific NotificationMessage that the client missed. This built-in recovery mechanism ensures data isn’t lost during network hiccups.
DeleteSubscriptions removes subscriptions and all their monitored items.
TransferSubscriptions moves subscriptions from one session to another. This is critical for client redundancy — a backup client can take over subscriptions from a failed primary without data loss.
NodeManagement Service Set
This service set modifies the address space structure itself.
AddNodes creates new nodes in the address space. You specify the node class, parent node, reference type, browse name, attributes, and type definition.
AddReferences creates new references between existing nodes.
DeleteNodes removes nodes from the address space.
DeleteReferences removes references between nodes.
These services are used during server configuration, not during normal data operations. Not all servers support them — many servers have a fixed address space defined at development time.
How Services Map to Real Tasks
Here’s how the services chain together for common real-world tasks.
Reading a single value: GetEndpoints → OpenSecureChannel → CreateSession → ActivateSession → Read → CloseSession → CloseSecureChannel.
Monitoring values in real time: (after session setup) → CreateSubscription → CreateMonitoredItems → Publish (repeated) → DeleteSubscriptions → CloseSession.
Browsing the server: (after session setup) → Browse (start at Root) → Browse (go deeper) → BrowseNext (if needed) → TranslateBrowsePathsToNodeIds (resolve specific paths) → Read (get values).
Calling a method: (after session setup) → Browse (find the method’s NodeId) → Call (invoke with arguments) → (process results).
OPC Classic vs OPC UA Services
If you’re coming from OPC Classic, here’s the key difference: OPC UA unified everything.
OPC Classic had separate interfaces for each data type. OPC DA had its own browse, read, write, and subscribe. OPC HDA had its own read for historical data. OPC A&E had its own event subscription. Each required separate code.
In OPC UA, one Read service reads current values, historical values, and event data. One Browse service navigates the entire address space — data access items, alarms, historical points, and methods all live in the same structure. One subscription model handles value changes, events, and alarm notifications.
This unification is a fundamental architectural improvement. Less code. Fewer interfaces. One consistent model for everything.
Conclusion
OPC UA’s ten service sets cover the full lifecycle of industrial communication — from discovering servers and establishing secure connections to reading data, calling methods, subscribing to changes, and managing the address space.
The services are abstract by design. They define what happens, not how it’s encoded or transported. This separation lets OPC UA evolve its transport mechanisms without breaking applications.
For developers, the good news is that OPC UA SDKs handle most of the low-level service mechanics. You typically work with higher-level APIs that wrap the services into familiar patterns — connect, browse, read, write, subscribe. But understanding the services underneath makes you better at troubleshooting, performance tuning, and designing robust industrial applications.
The services are the backbone of OPC UA. Everything else — the information model, security, companion specifications — depends on them to function.