A vendor that is developing a UA application, whether it is a Server application or a Client 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. Typically this will be multiple Profiles. Conformance to a single Profile may not yield a complete application. In most cases multiple Profiles are needed to yield a useful application. All Servers and Clients shall support at least a core Profile (Core Server Facet or Core Client Facet) and at least one Transport Profile
For example an HMI Client application may choose to support the “Core Client Facet”, the “UA-TCP UA-SC UA-Binary” Profile, the “Data Access Client Facet”, the “DataChange Subscriber Client Facet” and the “Attribute Write Client Facet”. If the Client is to be TestLab tested then it would also support “Base Client Behaviour” Profile. 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. It would also follow the best practice guideline for behaviour. Figure 2 illustrates the Profile hierarchy that this application may contain: This figure is only an illustration and the represented Profiles may change.
All 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 Read Services.
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.
Another example is an embedded device OPC UA Server application that may choose to support “Embedded UA Server” Profile and the “DataAccess Server Facet” Profile. This device would be a resource constrained device that would support UA-TCP, UA-Security, UA Binary encoding, data subscriptions and the DA data model. It may not support the optional attribute write. Figure 3 illustrates the hierarchy that this application may contain: This figure is just an illustration and the represented Profiles may change.
Another simple system Server application may choose to support: “Standard UA Server” Profile and the “DataAccess Server Facet” Profile. If the Server is to be lab tested then it would also support “Base Server Behaviour” Profile. This device would be a mid-level OPC UA Server that would support all that the embedded Server in the previous example supported and it would add support for an enhance level of the subscription service and support for writes. Figure 4 illustrates the hierarchy that this application may contain: This figure is just an illustration and the represented Profile may change.
If the example HMI Client were to connect to either of the example Servers, it may have to adjust its behavior based on the Profile reported by the respective Servers. If the HMI Client were communicating with the embedded device it would not be able to perform any write operations. It may also have to limit the number of subscriptions or sessions based on the performance limits of the Server. If the HMI Client is connected to the Standard Server it would be able to open additional windows, have higher limits on performance related items and it would be able to allow writes.