OPC Unified Architecture is highly decentralized and is mostly concerned with the standardization of the independent interactions between UA Applications (i.e. between Clients and Servers and between Publishers and Subscribers). However, as the number of Applications in a given system grows, there are advantages to having some information centralized and interactions that are uniform among all Applications in a system. For example, if a system consists of one Server and one or more Clients, it is reasonable for the Server to be configured with the usernames and passwords of all users that can access the Server. If instead a system has hundreds of Servers, then it becomes unmanageable for each Server to independently store and maintain the usernames and passwords for all users of the system. For scenarios like this, the Unified Architecture includes certain centralized, global components to provide consistency and alleviate administration burden.

Ideally all Applications should work with all the defined global services when they are present in a system, but Applications that wish to utilize a particular global service need to be designed and built to do so. Keep in mind that the use of the global services in a system is always optional, so Applications should not be written to require their presence.

Discovery Services allow OPC UA Applications to learn about other OPC UA Applications in a system and the necessary details on how to connect to them.

OPC UA defines three levels of dedicated Discovery Servers:

1. Local Discover Servery (LDS)
2. Local Discovery Server with multicast extension (LDS-ME)
3. Global Discovery Server (GDS)

OPC 10000-12 describes how to use the Discovery services with dedicated Discovery Servers.

OPC UA Applications rely on Digital (X.509) Certificates as the basis for trust. In systems it is highly desirable to assign and manage the Certificates used by the Applications centrally as they all need periodic maintenance (e.g., updates to trust lists and revocation lists, Certificate renewals, etc.). OPC 10000-12 describes the centralize Certificate management services.

Some OPC UA Applications may need to access external entities (e.g. authorization services, Brokers, etc.) that require an identifier and a secret (called a “key credential”) to be presented for access. The assignment and management of key credentials can be centralized using the services described in OPC 10000-12.

The authorization services described in OPC 10000-12 allows OPC UA Applications to delegate the user authentication, user management and the assignment of users to roles (see OPC 10000-18) to an external central entity (e.g. an OAuth2 server).

Historically, devices with network connectivity have been allowed to communicate as soon as they are plugged into the network. For enhanced security, many networks will now require that physical network devices be uniquely identified and authorized to communicate on the network before any additional network based provisioning can be done. For example, the assignment of a Certificate using the Certificate management services as described in 5.7.3.

OPC 10000-21 defines a standard process for devices to be allowed to communicate on the network so that OPC UA Applications can be installed, updated, and provisioned with Certificates over the network.

In large systems unique well-known names are often assigned to a piece of equipment, a measurement, or a control artifact. Such user-assigned names are often referred to as “Tag Names”. When a Node in a Server represents an entity with an assigned Tag Name, the Tag Name is often used as the Name or Description attribute for that Node, but short of browsing all Nodes in all Servers, there is no easy way to find a Node with a particular Name or Description. OPC 10000-17 defines a mechanism to assign a well-known name called an “alias name” to any Node in a Server and a centralized way to look up that Node by its alias name.

OPC UA Publishers and Subscribers utilize a security key service (SKS) to secure the messages sent between them. The SKS is responsible for managing the keys used to publish or consume the secured messages. The SKS may be implemented directly by a Publisher, or it may be centralized where a single SKS is used by a group of Publishers and Subscribers in a system. The SKS is described in OPC 10000-14.