The OPC Unified architecture multipart standard describes a number of Services and a variety of information models. These Services and information models can be referred to as features of a Server or Client. Servers and Clients need to be able to describe which features they support and wish to have certified. This document provides a grouping of these features. The individual features are grouped into ConformanceUnits which are further grouped into Profiles. Figure 1 provides an overview of the interactions between Profiles, ConformanceUnits and TestCases. The large arrows indicate the components that are used to construct the parent. For example a Profile is constructed from Profiles and ConformanceUnits. The figure also illustrates a feature of the OPC UA Compliance Test Tool (CTT), in that it will test if a requested Profile passes all ConformanceUnits. It will also test all other ConformanceUnits and report any other Profiles that pass conformance testing. The individual TestCases are defined in separate documents see Compliance Part 8 UA Server and Compliance Part 9 UA Client. The TestCases are related back to the appropriate ConformanceUnits defined in this standard. This relationship is also displayed by the OPC UA Compliance Test Tool.


Figure 1 – Profile – ConformanceUnit – TestCases

Each ConformanceUnit represents a specific set of features (e.g. a group of services, portions of services or information models) that can be tested as a single entity. ConformanceUnits are the building blocks of a Profile. Each ConformanceUnit can also be used as a test category. For each ConformanceUnit, there would be a number of TestCases that test the functionality described by the ConformanceUnit. The description of a ConformanceUnit is intended to provide enough information to illustrate the required functionality, but in many cases to obtain a complete understanding of the ConformanceUnit the reader may be required to also examine the appropriate part of OPC UA. Additional Information regarding testing of a ConformanceUnit are provided in the Compliance Part 8 UA Server or Compliance Part 9 UA Client test standards.

The same features do not appear in more than one ConformanceUnit.

For improved clarity, the large list of ConformanceUnits is arranged into named ConformanceGroups. These groups reflect different OPC UA aspects like the Service Sets, security, transport, and Information Models.

ConformanceGroups have no impact on testing; they are used only for organizational reasons. These groups and the ConformanceUnits that they describe are available at

A Profile is a named aggregation of ConformanceUnits and other Profiles. To support a Profile, an application has to support the ConformanceUnits and all aggregated Profiles. The definition of Profiles is an ongoing activity, in that it is expected that new Profiles will be added in the future.

Multiple Profiles may include the same ConformanceUnit.

Testing of a Profile consists of testing the individual ConformanceUnits that comprise the Profile.

Profiles are named based on naming conventions (see 4.5 for details).

Profiles are grouped into categories to help vendors and end users understand the applicability of a Profile.

Table 1 contains the list of currently defined ProfileCategories.

Table 1 – Profile Categories



Application Profiles

Application level Profiles represent a collection of Facets necessary to build a functional OPC UA Application.They specifically include Transport Profiles and generally also Security Profiles.


Profiles of this category specify functions of an OPC UA Server. The URI of such Profiles can be exposed in the Server capabilities.


Profiles of this category specify functions of an OPC UA Client.


Profiles of this category specify functions of an OPC UA Publisher.


Profiles of this category specify functions of an OPC UA Subscriber.


Profiles of this category specify specific protocol mappings. The URI of such Profiles has to be part of an Endpoint Description.


Profiles of this category specify security related functions. Security policies are part of this category. The URI of Client-Server security policies has to be part of an Endpoint Description returned from the GetEndpoints Service.

Global Directory Service

Profiles of this category specify functions for global discovery and certificate management.

An OPC UA application shall implement all mandatory ConformanceUnits in a Profile in order to be compliant with the Profile. Some Profiles contain optional ConformanceUnits. Optional means that an application has the option to not support the ConformanceUnit. However, if supported, the application shall pass all tests associated with the ConformanceUnit. If an OPC UA application desires to be listed as supporting the optional ConformanceUnit then it shall include any required information model items in the configuration provided for certification testing. The test result that is generated by the certification testing lists all optional ConformanceUnits and whether they are supported or not by the tested OPC UA application.

Profiles may also include other Profiles. If a Profile is included it means that it is mandatory and the same conformance rules apply to it.

Profiles have the following naming conventions:

  • Profiles intended for specific application types have the application type in their titles. Currently defined application types are Server, Client, Publisher, Subscriber, and GDS.
  • The term Facet in the title of a Profile indicates that this Profile concerns a specific feature of OPC UA. Such Profiles are expected to be combined with Application Profiles to define the complete functionality of an OPC UA application.

Versioning of Profile is accomplished with a naming convention. Whenever a profile is revised, the year of the new revision is added to the name. Example:

Version 1

Core Server Facet

Version 2

Core 2017 Server Facet

Version 3

Core 2022 Server Facet

A vendor that is developing an OPC UA application, shall review the list of available Profiles. From this list the vendor shall select the Profiles that include the functionality required by the application. Conformance to a single Profile may not yield a complete application. In most cases multiple Profiles are needed to yield a useful application. All UA applications shall support at least one Application Profile.

For example an HMI Client application may choose to support the Minimum UA Client 2022 Profile, the “Data Access Client Facet”, the “DataChange Subscriber Client Facet” and the “Attribute Write Client Facet”. This list of Profiles would allow the Client to communicate with an OPC UA Server using UA-TCP/UA Security/UA Binary. It would be able to subscribe for data, write to data and would support the DA data model.

Clients should take into account the types of Servers and Server Profiles that they are targeted to support. Some Servers might not support Subscriptions and Clients should be able to fall back to the Read Service.

A special case is a generic Client that is designed to communicate with a large number of Servers and therefore able to perform a broad range of functionality. ”Standard UA Client Profile” has been defined for this kind of Clients.

Many Clients, however, will be specialized and do not need all of the functionality in the ”Standard UA Client Profile” and thus would only support the limited set of functionality they require. A trend Client, for example, would only need functionality to subscribe to or read data.