Companion specification · Tier 1

GDS

DocumentOPC 10000-12
Version1.05.07
Published2026-05-01
Namespacehttp://opcfoundation.org/UA/GDS/
SectorGlobal services

The Global Discovery Server information model (Part 12) standardises fleet certificate management. It defines the certificate directory a device asks for a certificate (pull), the ServerConfiguration and TrustList objects through which a GDS pushes certificates and trust lists to a server (push), plus key credential and authorization services.

Where it sits in the stack

GDS is core infrastructure rather than a machine model, versioned with the core specification at 1.05.07. It is distinct from the Local Discovery Server, which is the thing listening on port 4840 answering FindServers and RegisterServer and advertising the local discovery facet; a GDS does registration, discovery and certificate management across a plant. Its server capability code is GDS, and LDS is separate. Part 12 also owns the standard PKI folder layout that the SDKs implement.

The types that matter

TypeWhat it carries
CertificateDirectoryTypeThe GDS-side object a device or an administrator talks to in order to register an application and obtain certificates. It is the entry point for the pull model.
RegisterApplicationMethod that records an application with the GDS, keyed on its ApplicationUri and product information. Registration precedes certificate issuance.
StartSigningRequestMethod for the pull model where the device keeps its own private key and sends a certificate signing request. This is the option to prefer whenever the device can generate a key.
StartNewKeyPairRequestMethod where the GDS generates the key pair and returns the private key. Convenient for constrained devices and a custody question you should answer deliberately.
FinishRequestMethod that collects the issued certificate, the issuer chain and the CRLs once the request has been processed. Requests are asynchronous by design.
GetTrustListMethod returning the trust list the GDS maintains for an application, so a device can align its trust anchors with the plant's rather than accumulating peers ad hoc.
ServerConfigurationTypeThe object a server exposes so that certificates and trust lists can be pushed to it over OPC UA itself. This is the push model, and it is what makes fleet rollout feasible.
UpdateCertificateMethod on ServerConfiguration that installs a new application instance certificate, with or without a matching private key.
CreateSigningRequestMethod on ServerConfiguration that has the server produce a signing request, so the push model can also work without the private key ever leaving the device.
TrustListTypeThe trust list exposed as a file-like object, read and written with the file-transfer pattern, with masks to address trusted certificates, issuers and CRLs separately.
CertificateGroupTypeGroups the certificate and trust list for one purpose, such as the application group or an HTTPS group, and identifies which certificate types are supported.
ApplyChangesMethod that activates pushed changes. Forgetting it is the classic reason a certificate update appears to have worked and nothing changes until the next restart.

Using it on a real machine

  1. Decide pull or push before buying anythingPull suits devices that can reach a GDS and generate keys. Push suits servers already deployed that expose ServerConfiguration. Most plants end up with both, and the decision determines your rollout tooling.
  2. Get the PKI layout right firstUse the Part 12 Annex F.1 folder structure: own for this application's certificate and key, trusted for trust anchors, issuer for chain-completion CA certificates that are not themselves trusted, rejected for failed peers, with parallel user and HTTPS stores. Confusing issuer with trusted is the most common PKI mistake in OPC UA.
  3. Check your CA certificates carry both key usage bitsOPC UA requires every CA certificate in a chain to assert keyCertSign and cRLSign. Corporate CAs that omit cRLSign break OPC UA, often reporting only an unhelpful BadCertificateInvalid.
  4. Include SubjectAltName correctlyEvery application instance certificate needs its ApplicationUri as a URI entry in SubjectAltName plus the DNS names and IPs used to reach the endpoint, or validation fails on the URI and hostname checks.
  5. Push, then apply, then verifyCall UpdateCertificate or write the trust list, then ApplyChanges, then reconnect and confirm the new certificate is in use and the rejected store is empty. Skipping the verification step is how a fleet ends up half migrated.
  6. Ship CRLs with the trust listA trust list without current revocation lists produces revocation-unknown failures that engineers then suppress, which quietly removes the security benefit you deployed the GDS for.

What it gives you for OEE

Nothing directly: GDS carries no machine state, counts or reasons. Its relevance to a data-collection project is scheduling, and it is not small. Certificate trust is consistently the biggest practical obstacle to getting a client connected to plant equipment, and on a fleet of any size doing it by hand does not scale: each machine needs the collector's certificate accepted, each trust list needs maintaining, and each expiry is an outage waiting to happen. Deciding on a PKI approach, even a documented manual trust-list procedure, before the first machine is connected is what keeps an OEE rollout on schedule.

Try it free: There is no public GDS to point a client at, and neither the umati server nor the public Milo and node-opcua demos expose one. The realistic exercise is local and worth doing once: build the Part 12 folder layout by hand, generate an application instance certificate with the correct SubjectAltName, and walk a trust failure end to end against a demo server, for example connecting to opc.tcp://milo.digitalpetri.com:62541/milo with security enabled and watching your certificate land in the rejected store before you trust it. Then repeat the exercise using a server that exposes ServerConfiguration so you can see the push methods work.

Gotchas

  • An LDS is not a GDS. The thing on port 4840 answering FindServers is a Local Discovery Server; certificate management is a different service with a different capability code.
  • Push requires the server to expose ServerConfiguration and to grant your user the rights to use it. Many embedded servers do not, which forces a manual or pull approach on exactly the devices where manual is most painful.
  • ApplyChanges is easy to forget, and without it a pushed certificate sits inactive until a restart, which looks like a failed push.
  • Private-key custody is a policy decision. StartNewKeyPairRequest means the key travels; keys can also live in a TPM, smart card or HSM and never enter process memory. Decide before rollout, not after an audit.

Once the machine speaks a companion spec, the OEE mapping is portable across vendors, which is the point at which analytics stops being a per-machine project.

See Jemba →

Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.

Free download
OPC UA Machine Data → OEE Mapping Kit
Which nodes to subscribe to, how they become Availability, Performance and Quality, and which companion specification already gives you the answer, so you stop inventing tags.
Get the free mapping kit →
Free, no course, no login