OPC UA made industrial systems easier to connect, configure, secure and scale. One of the improvements introduced by OPC UA is its standardized discovery mechanism.
In OPC Classic, clients relied on OPC Enum, a Windows service that enumerated installed OPC servers on a local or remote machine using Microsoft DCOM. While OPC Enum simplified server discovery compared to manually entering ProgIDs or CLSIDs, it remained dependent on DCOM configuration and Windows networking, making discovery across firewalls or distributed environments complex and difficult to manage.
OPC UA replaces this approach with built-in discovery services that enable clients to automatically locate available servers, endpoints, and supported security policies using standardized OPC UA services. As specified in OPC UA spec part12 – Discovery, OPC UA defines two discovery services:
- Local Discovery Server (LDS)
- Global Discovery Server (GDS)
Although they share similar names, they solve different problems. Understanding the role of each is essential for designing scalable and secure OPC UA architectures.
In this article, we will explain how OPC UA discovery works, compare LDS and GDS, and discuss when each should be used.
Why Does OPC UA Need Discovery?
Imagine a manufacturing facility with:
- 50 PLCs exposing OPC UA servers
- Multiple SCADA systems
- An MES platform
- A historian
- Several engineering workstations
- Edge gateways collecting production data
Every client application must know which OPC UA servers are available and how to connect to them.
Without discovery, every endpoint must be configured manually:
- Server URL
- Port number
- Security policy
- Message security mode
- Application information
Whenever a server changes its address or a new system is added, every affected client must be updated manually.
Discovery eliminates much of this administrative effort by allowing applications to locate OPC UA servers dynamically.
What Is OPC UA Discovery?
OPC UA Discovery is a standardized mechanism that enables OPC UA clients to find available servers without requiring their addresses to be manually configured.
Discovery provides information such as:
- Available OPC UA servers
- Application name
- Application URI
- Product URI
- Discovery URLs
- Communication endpoints
- Supported security policies
- Security modes
This allows OPC UA client applications to automatically identify compatible servers.
How Discovery Works
At a high level, the discovery process follows these steps:
Figure 1: High-level OPC UA Discovery Process
The discovery service acts as a directory, allowing clients to locate servers before establishing secure communications.
What Is a Local Discovery Server (LDS)?
A Local Discovery Server (LDS) is a lightweight OPC UA service that runs on an individual computer or industrial device. Its purpose is to maintain a directory of OPC UA servers running on the local machine.
Whenever an OPC UA server starts, it can register itself with the LDS. Clients connecting to that computer can then query the LDS to discover all locally available OPC UA servers.
By default, an LDS is scoped to the machine it runs on. However, the OPC UA specification also defines an optional Multicast Extension (LDS-ME), which lets the LDS advertise itself using mDNS (Multicast DNS). When enabled, a client can call the FindServersOnNetwork service to discover OPC UA servers registered with any LDS-ME on the same subnet and not just the local machine. This extends an LDS’s reach across a local network segment, though it still stops at subnet boundaries and depends on multicast being permitted on the network. Some network administrators do disable multicast for security reasons, since mDNS traffic is inherently unauthenticated.
What Information Does an LDS Store?
A registered OPC UA server application typically provides:
- Application Name
- Application URI
- Product URI
- Discovery URL
- Endpoint URLs
- Supported security policies
- Available transport profiles
The LDS simply stores this information and makes it available to requesting OPC UA clients. It does not inspect process data or participate in communications between clients and servers.
Figure 2: Typical LDS Architecture
Want to see OPC UA discovery in action? Our OPC UA Client Toolkit includes built-in server discovery via LDS.
Advantages of an LDS
An LDS offers several benefits:
- Simplified Configuration
Clients no longer need manually maintained endpoint lists.
- Automatic & Standardized Discovery
New OPC UA servers become discoverable immediately after registration.
Discovery behaves consistently across products from different vendors.
Limitations of an LDS
Although useful, an LDS has important limitations. It does not:
- Discover servers beyond its local subnet (even with the multicast extension enabled, an LDS’s reach stops at subnet boundaries)
- Manage certificates
- Distribute trust lists
- Renew certificates
- Revoke certificates
- Act as a Certificate Authority
Its scope is intentionally limited to local discovery.
What Is a Global Discovery Server (GDS)?
As industrial environments grow, discovery across a single computer is not sufficient.
Organizations often operate hundreds of OPC UA servers, multiple production sites, cloud-connected applications, historians, MES systems, enterprise analytics platforms, etc.
Managing these applications individually quickly becomes difficult.
The Global Discovery Server (GDS) addresses this challenge by providing centralized application discovery across an entire organization. Unlike the LDS, the GDS also manages the security lifecycle of OPC UA applications.
What Does a GDS Do?
A GDS provides two major capabilities:
- Enterprise-Wide Discovery
Applications register themselves with the GDS. OPC UA Clients can then discover OPC UA servers anywhere within the enterprise.
The GDS stores information including application name, application URI, discovery URLs, available endpoints, and supported security policies.
- Certificate Management
One of the most important responsibilities of a GDS is managing OPC UA application certificates. A GDS can:
- Issue certificates
- Renew certificates
- Revoke certificates
- Maintain trust lists
- Distribute trusted certificates
Architecturally, a GDS is itself a complete OPC UA Server – not a lightweight directory like an LDS. Because of this, all interactions with a GDS (registering an application, querying for servers, managing certificates) happen over an authenticated, secured OPC UA session rather than an open discovery call. This is an important distinction: it means GDS communication is secured by design, and it is part of why the GDS is the component trusted to issue and manage certificates on behalf of other applications.
Figure 3: Typical GDS Architecture
Unlike an LDS, a GDS can manage applications across multiple computers, production lines, and even geographically distributed facilities.
LDS vs. GDS
The following table summarizes the differences between the two discovery services.
| Feature | Local Discovery Server (LDS) | Global Discovery Server (GDS) |
| Scope | Single computer (subnet-wide with LDS-ME) | Entire enterprise |
| Server discovery | ✔ | ✔ |
| Application registration | Local only | Enterprise-wide |
| Requires authenticated session | ✖ (open discovery queries) | ✔ (secured OPC UA session) |
| Certificate management | ✖ | ✔ |
| Trust list management | ✖ | ✔ |
| Automatic certificate renewal | ✖ | ✔ |
| Certificate revocation | ✖ | ✔ |
| Multi-site support | ✖ | ✔ |
| Scalability | Limited | Supported |
How LDS and GDS Work Together
The LDS and GDS are complementary rather than competing technologies. A typical workflow looks like this:
- An OPC UA server starts.
- The server registers with the LDS on its host computer.
- The server also registers with the GDS.
- The GDS validates or issues the server’s certificate.
- OPC UA Clients discover servers locally through the LDS or enterprise-wide through the GDS.
Do You Always Need an LDS / a GDS?
Not necessarily. Many OPC UA clients already know the endpoint address of the server they need to connect to. In these situations, discovery is optional.
An LDS is most useful when:
- Multiple OPC UA servers run on one machine.
- Engineering software needs to browse available servers.
- Dynamic discovery simplifies deployment.
For a small system with one or two OPC UA servers, manually managing certificates is often acceptable. A GDS becomes increasingly valuable when:
- The number of OPC UA applications grows.
- Multiple facilities are involved.
- Certificate management becomes difficult.
- Security policies must be centrally enforced.
- Enterprise-wide scalability is required.
In either case, confirm that the specific products in your architecture actually support what you’re planning around – LDS support is close to universal, but GDS support still varies more by vendor and version.
Frequently Asked Questions
What about a GDS - is that mandatory?
Also no. The GDS is optional but highly recommended for medium and large deployments where centralized certificate management improves security and reduces administrative effort. For small setups, the added complexity often outweighs the benefits.
Can LDS and GDS run side by side?
Yes. Many enterprise deployments use an LDS for local discovery and a GDS for centralized discovery and certificate management.
Does the GDS replace the LDS?
No. The two services complement each other. The LDS provides local discovery, while the GDS provides enterprise-wide discovery and centralized security management. Think of it less as replacement and more as division of labor: LDS answers "what is running on this machine," GDS answers "what is running anywhere, and can I trust it."
Is LDS an OPC UA server?
Sort of. An LDS is implemented as a special-purpose OPC UA server — it exposes the standard FindServers and RegisterServer2 services over an OPC UA endpoint (typically opc.tcp://host:4840/UADiscovery). However, it is not a general-purpose OPC UA server that exposes process data.
Does GDS support come standard with most OPC UA products?
Not as reliably as you would expect. LDS support has been near-universal for years, but GDS is newer territory. Some major industrial platforms only added it in the last release or two, and others still do not support it natively. Before planning around a GDS, it is worth confirming that every OPC UA application in your architecture actually supports GDS registration and certificate push/pull, rather than assuming it is a universally available option the way LDS is.
Looking for Free OPC UA Products?
If you are looking for OPC UA test products, click here to download a free OPC UA Server Simulator and here to download a free OPC UA Client.
