A vendor that is developing a UA application, whether it is a Serverapplication or a Clientapplication, shall review the list of available Profiles. From this list the vendor shall select the Profilesthat include the functionality required by the application. Typically this will be multiple Profiles. Conformance to a single Profilemay not yield a complete application. In most cases multiple Profilesare needed to yield a useful application. All Serversand Clientsshall support at least a core Profile (Core Server Facetor Core Client Facet) and at least one Transport Profile
For example an HMI Clientapplication may choose to support the “Core Client Facet”, the “UA-TCP UA-SC UA-Binary” Profile, the “Data Access Client Facet”, the “DataChange Subscriber ClientFacet” and the “AttributeWrite Client Facet”. If the Clientis to be TestLabtested then it would also support “Base ClientBehaviour” Profile. This list of Profileswould allow the Clientto communicate with an OPC UA Serverusing 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 2illustrates the Profilehierarchy that this application may contain: This figure is only an illustration and the represented Profilesmay change.
All Clientsshould take into account the types of Serversand Server Profilesthat they are targeted to support. Some Serversmight not support Subscriptionsand Clientsshould be able to fall back to Read Services.
A special case is a generic Clientthat is designed to communicate with a large number of Serversand 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 Serverapplication that may choose to support “Embedded UA Server” Profileand the “DataAccess ServerFacet” 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 3illustrates the hierarchy that this application may contain: This figure is just an illustration and the represented Profilesmay change.
Another simple system Serverapplication may choose to support: “Standard UA Server” Profileand the “DataAccess ServerFacet” Profile. If the Serveris to be lab tested then it would also support “Base ServerBehaviour” Profile. This device would be a mid-level OPC UA Serverthat would support all that the embedded Serverin the previous example supported and it would add support for an enhance level of the subscription service and support for writes. Figure 4illustrates the hierarchy that this application may contain: This figure is just an illustration and the represented Profilemay change.
If the example HMI Clientwere to connect to either of the example Servers, it may have to adjust its behavior based on the Profilereported by the respective Servers. If the HMI Clientwere 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 Clientis connected to the Standard Serverit would be able to open additional windows, have higher limits on performance related items and it would be able to allow writes.