The OPC UA Client-Server Model is a connection-oriented communication pattern where a Client application initiates a secure Session with a Server to exchange data and execute operations. The Server exposes its Address Space—a structured graph of Nodes representing real-time data, historical records, and system capabilities—while the Client requests specific services like Data Access reads, writes, or Monitored Item subscriptions for event-driven updates.
Glossary
Client-Server Model
The OPC UA communication pattern where a client initiates a session to request and receive data, browse the Address Space, and call methods on a server.
COMMUNICATION PATTERN
What is the OPC UA Client-Server Model?
The foundational communication pattern in OPC UA where a client application initiates a secure session to request data, browse the Address Space, and invoke methods on a server application.
This model relies on a stateful, long-lived Session established over a Secure Channel, which provides encryption, message signing, and application authentication via X.509 Certificates. Unlike the decoupled Pub-Sub Model, the Client-Server pattern maintains strict context and continuity, enabling complex interactions such as browsing type hierarchies, acknowledging Alarms and Conditions, and calling custom Methods on server-side objects.
OPC UA COMMUNICATION PATTERNS
Key Features of the Client-Server Model
The OPC UA Client-Server model defines a structured, session-based relationship where the Client initiates all communication, and the Server responds, exposing its Address Space for discovery, data access, and method execution.
01
Session-Oriented Statefulness
Unlike stateless web protocols, the OPC UA Client-Server model establishes a long-lived Session over a Secure Channel. This session maintains critical context, including user authentication, negotiated settings, and outstanding operations. If a connection drops, the session can be recovered, preserving Monitored Items and Subscriptions without requiring a complete re-initialization. This stateful design is essential for maintaining continuity in industrial automation where re-subscribing to thousands of data points would be prohibitively expensive and slow.
02
Service-Oriented Request/Response
All interactions are structured as atomic service calls initiated by the Client. The Server processes these requests and returns a corresponding response. Core service sets include:
- Data Access: Read, Write, and Monitor current values of Variable Nodes.
- Alarms & Conditions: Acknowledge and manage stateful event notifications.
- Historical Access: Query aggregated time-series data from the Server's historian.
- Method Services: Invoke server-side functions that execute complex logic, such as a calibration routine or a batch start command, going beyond simple data exchange.
03
Address Space Browsing
A Client does not need prior knowledge of a Server's data layout. It can dynamically browse the Address Space, a hierarchical graph of Nodes and References. This allows the Client to discover available objects, variables, and their semantic relationships defined by Information Models. For example, a generic HMI client can connect to a CNC machine's Server, browse its 'Machinery' Companion Specification nodes, and automatically render an operator interface without custom code, enabling true plug-and-produce interoperability.
04
Subscription-Based Data Monitoring
For efficient real-time data transfer, the Client creates a Subscription that groups multiple Monitored Items. Instead of polling, the Server publishes data changes only when they occur, based on configurable criteria. This is optimized by:
- Sampling Interval: The rate at which the Server checks the value.
- Publishing Interval: The rate at which queued changes are sent.
- Deadband Filter: Suppresses notifications unless the absolute value change exceeds a defined threshold, drastically reducing network load for noisy analog signals like vibration sensors.
05
Robust Security Handshake
Security is established before any application data flows. The Client connects to a specific Endpoint exposed by the Server, which dictates the required Security Policy (e.g., Basic256Sha256) and authentication mode. The handshake involves an exchange and validation of X.509 Certificates to establish mutual trust. Once the Secure Channel is active, all messages are encrypted and signed, ensuring confidentiality and integrity. This prevents man-in-the-middle attacks and unauthorized control on the factory floor.
06
Role-Based Access Control
Beyond session authentication, the Server can enforce fine-grained authorization using Role-Based Access Control (RBAC). Administrators assign specific roles (e.g., 'Operator', 'Maintenance Engineer', 'Commissioner') to user identities. These roles are then mapped to permissions on individual Nodes in the Address Space. A maintenance engineer might have the right to call a 'Reset' method on a drive, while an operator can only read its status, preventing unauthorized execution of critical commands.
CLIENT-SERVER MODEL IN OPC UA
Frequently Asked Questions
The client-server model is the foundational communication pattern in OPC Unified Architecture, defining how industrial applications request and exchange data. These answers address the most common architectural and operational questions from automation engineers and CTOs implementing secure, session-based connectivity.
The OPC UA Client-Server Model is a connection-oriented communication pattern where a Client application initiates a secure session to a Server to request data, browse the Address Space, and call methods. The Server passively listens for incoming connection requests on configured Endpoints, authenticates the Client using X.509 Certificates, and establishes a Session over a Secure Channel. Once the session is active, the Client can execute service requests like Read, Write, Subscribe, and Call. The Server processes these requests against its Address Space and returns responses. This model is inherently asymmetric: the Client always initiates, and the Server responds. It is ideal for supervisory control, HMI visualization, and on-demand data access where a central application polls or subscribes to data from multiple industrial controllers.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read more
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us