The following table shows the different OPC UA profiles and if they are supported by the OPC UA Server .NET:
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Core 2017 Server Facet | This Facet defines the core functionality required for any UA Server implementation. The core functionality includes the ability to discover endpoints, establish secure communication channels, create Sessions, browse the AddressSpace and read and/or write to Attributes of Nodes. The key requirements are: support for a single Session, support for the Server and Server Capabilities Object, all mandatory Attributes for Nodes in the AddressSpace, and authentication with UserName and Password. For broad applicability, it is recommended that Servers support multiple transport and security Profiles. It supersedes the Core Server Facet. | X | Yes | |
| Core 2022 Server Facet | This Facet defines the core functionality required for any UA Server implementation. The core functionality includes the ability to discover endpoints, establish secure communication channels, create Sessions, browse the AddressSpace and read and/or write to Attributes of Nodes. The key requirements are: support for minimum one Session, support for the core AddressSpace structure, and the Server Capabilities Object, and authentication with UserName and Password. For broad applicability, it is recommended that Servers support multiple transport and security Profiles. It supersedes the Core 2017 Server Facet. | X | Yes | |
| Exposes Type System Server Facet | This Facet defines the ability to expose meta data in the AddressSpace, i.e. data that describe the various OPC UA Types used by the Server.Note that each Node defined in the core specification parts has ConformanceUnits defined that require the Node to be in the AddressSpace. If a Server supports such a ConformanceUnit, it shall expose the Nodes related to the ConformanceUnit in its AddressSpace. | X | No | |
| Base Server Behaviour Facet | This Facet defines best practices for the configuration and management of Servers when they are deployed in a production environment. It provides the ability to enable or disable certain protocols and to configure the Discovery Server and specify where this Server shall be registered. Note: Base Server Facet is supported but Compliance Test Tool doesn’t support any test cases for this. | X | Yes | |
| Method Server Facet | This Facet specifies the support of Method invocation via the Call service. Methods are “lightweight” functions which are like the methods of a class found in any object-oriented programming language. A Method can have its scope bounded by an owning Object or an owning ObjectType. Methods with an ObjectType as their scope are like static methods in a class. | X | Yes | |
| Method 2022 Server Facet | This Facet specifies the support of Method invocation via the Call service. Methods are “lightweight” functions which are like the methods of a class found in any object-oriented programming language. A Method can have its scope bounded by an owning Object or an owning ObjectType. Methods with an ObjectType as their scope are like static methods in a class. | X | Yes | |
| File Access Server Facet | This Facet specifies the support of exposing File information via the defined FileType. This includes reading of file as well as optionally writing of file data. | X | No | |
| Temporary File Access Server Facet | This Facet specifies the support of creating and accessing temporary files. This includes one of the defined access forms. | X | No | |
| Dictionary Reference Server Facet | This Facet specifies the support of Dictionary References to relate Nodes in the AddressSpace to external dictionaries. | X | No | |
| AliasName Server Facet | Defines the use of AliasNames in a Server. | X | No | |
| AliasName Aggregating Server Facet | Defines the use of AliasNames in an aggregating Server. | X | No | |
| State Machine Server Facet | This Facet defines support of StateMachines based on the types in UA Part 5. | X | No | |
| State Machine 2022 Server Facet | This Facet defines support of StateMachines based on the types in UA Part "State Machines". This Facet supersedes the State Machine Server Facet. | X | No | |
| Scheduler Base Server Facet | A Facet that describes the base characteristics for OPC UA Servers that support exposing schedules. | X | No | |
| Scheduler Base Server Facet | A Facet that describes the base characteristics for OPC UA Servers that support exposing schedules. | X | No | |
| Scheduler Configuration Server Facet | A Facet that describes the base characteristics for OPC UA Servers that support configuring schedules. | X | No | |
| Node Management Server Facet | This Facet requires the support of the Services that allow the Client to add, modify and delete Nodes in the AddressSpace. These Services provide an interface which can be used to configure Servers. This means all changes to the AddressSpace are expected to persist even after the Client has disconnected from the Server. | X | No | |
| Node Management 2022 Server Facet | This Facet requires the support of the Services that allow the Client to add, modify and delete Nodes in the AddressSpace. These Services provide an interface which can be used to configure Servers. This means all changes to the AddressSpace are expected to persist even after the Client has disconnected from the Server. This Facet supersedes the Node Management Server Facet. | X | No | |
| Attribute WriteMask Server Facet | This Facet defines the capability to update characteristics of individual Nodes in the AddressSpace by allowing writing to Node Attributes. It requires support for authenticating user access as well as providing information related to access rights in the AddressSpace and actually restricting the access rights as described. Note: in the future this Facet will be Deprecated and replaced by Attribute WriteMask Server 2023 Facet | X | Yes | |
| Attribute WriteMask Server 2023 Facet | This Facet defines the capability to update characteristics of individual Nodes in the AddressSpace by allowing writing to Node Attributes. It requires support for authenticating user access as well as providing information related to access rights in the AddressSpace and actually restricting the access rights as described. | X | Yes | |
| Publisher Information Model Facet | This Facet requires that the Publisher is an OPC UA Server and exposes its configuration using the OPC UA PubSub Information Model. | X | No | |
| Subscriber Information Model Facet | This Facet requires that the Subscriber is an OPC UA Server and exposes its configuration using the OPC UA PubSub Information Model. | X | No | |
| Documentation Server Facet | This Facet defines a list of user documentation that a server application should provide. | X | No |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Subnet Discovery Server Facet | Support of this Facet enables discovery of the Server on a subnet using mDNS. This functionality is only applicable when Servers do not register with an LDS. | X | No | |
| Reverse Connect Server Facet | This Facet defines support of reverse connectivity in a Server. Usually, a connection is opened by the Client before starting the UA-specific handshake. This will fail, however, when Servers are behind firewalls with no open ports to connect to. In the reverse connectivity scenario, the Server opens the connection and starts with a ReverseHello message requesting that the Client establish a Secure Channel using this connection. | X | No | |
| Sessionless Server Facet | Defines the use of Sessionless Service invocation in a Server. | X | No |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Global Certificate Management Server Facet | This Facet defines the capability to interact with a Global Certificate Management Server to obtain an initial or renewed Certificate and Trust Lists. | X | No | |
| Authorization Service Server Facet | This Facet defines the support for configuring the necessary information to validate access tokens when presented by a Client during session establishment. Access Tokens are issued by Authorization Services. | X | No | |
| KeyCredential Service Server Facet | This Facet defines the capability to interact with a KeyCredential Service to obtain KeyCredentials. For example, KeyCredentials are needed to access an Authorization Service or a Broker. The KeyCredential Service is typically part of a system-wide tool, like a GDS that also manages Applications, Access Tokens, and Certificates. | X | No |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| User Role Base Server Facet | This Facet defines support of the OPC UA Information Model to expose configured user roles and permissions. | X | No | |
| User Role Management Server Facet | This Facet defines support of the OPC UA approach to manage user roles and permissions and to grant access to Nodes and Services based on the assigned roles and permissions. | X | No | |
| User Token – Anonymous Server Facet | This Facet indicates that the Server supports anonymous User Tokens. | X | Yes | |
| User Token – User Name Password Server Facet | This Facet indicates that a user token that is comprised of a username and password is supported. This user token can affect the behaviour of the ActivateSession Service. | X | Yes | |
| User Token – X509 Certificate Server Facet | This Facet indicates that the use of an X509 certificates to identify users is supported. | X | Yes | |
| User Token – JWT Server Facet | This Facet defines support for JSON Web Tokens (JWT) to identify the user during Session setup. A JWT is the Access Token format which OPC UA requires when using OAuth2. | X | No | |
| User Token – Issued Token Server Facet | This Facet indicates that a User Token that is comprised of an issued token is supported. | X | No | |
| User Token – Issued Token Windows Server Facet | This Facet further refines the User Token - Issued Token to indicate a windows implementation of Kerberos | X | No |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Embedded DataChange Subscription Server Facet | This Facet specifies the minimum level of support for data change notifications within subscriptions. It includes limits which minimize memory and processing overhead required to implement the Facet. This Facet includes functionality to create, modify and delete Subscriptions and to add, modify and remove Monitored Items. As a minimum for each Session, Servers shall support one Subscription with up to two items. In addition, support for two parallel Publish requests is required. This Facet is geared for a platform such as the one provided by the Micro Embedded Device Server Profile in which memory is limited and needs to be managed. | X | No | |
| Standard DataChange Subscription 2017 Server Facet | This Facet specifies the standard support of subscribing to data changes and extends features and limits defined by the Embedded Data Change Subscription Facet. See ConformanceUnits for these limits. Note that the Method Call Service is only required for the Methods defined in this Facet. This Facet supersedes the "Standard DataChange Subscription Server Facet". | X | Yes | |
| Enhanced DataChange Subscription 2017 Server Facet | This Facet specifies an enhanced support of subscribing to data changes. It is part of the Standard UA Server 2017 Profile. This Facet increases the limits defined by the Standard Data Change Subscription 2017 Server Facet. Note: Enhanced DataChange Subscription 2017 Server Facet is supported in a basic form. | X | Yes | |
| Durable Subscription Server Facet | This Facet specifies support of durable storage of data and events even when Clients are disconnected. This Facet implies support of any of the DataChange or Event Subscription Facets. | X | No | |
| Data Access Server Facet | This Facet specifies the support for an Information Model used to provide industrial automation data. This model defines standard structures for analog and discrete data items and their quality of service. This Facet extends the Core Server Facet which includes support of the basic AddressSpace behaviour. | X | Yes | |
| ComplexType 2017 Server Facet | This Facet extends the Core Server Facet to include Variables with structured data, i.e. data that are composed of multiple elements such as a structure and where the individual elements are exposed as component variables. Support of this Facet requires the implementation of structured DataTypes and Variables that make use of these DataTypes. The Read, Write and Subscriptions service set shall support the encoding and decoding of these structured DataTypes. As an option the Server can also support alternate encodings, such as an XML encoding when the binary protocol is currently used and vice-versa. Note: ComplexType 2017 Server Facet is supported in a basic form, but Compliance Test Tool doesn’t support any test cases for this. | X | Yes |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Standard Event Subscription Server Facet | This Facet specifies the standard support for subscribing to events and is intended to supplement any of the FullFeatured Profiles. Support of this Facet requires the implementation of Event Types representing the Events that the Server can report and their specific fields. It also requires at least the Server Object to have the EventNotifier Attribute set. It includes the Services to Create, Modify and Delete Subscriptions and to Add, Modify and Remove Monitored Items for Object Nodes with an “EventNotifier Attribute”. Creating a monitoring item may include a filter that includes SimpleAttribute FilterOperands and a select list of Operators. The operators include: Equals, IsNull, GreaterThan, LessThan, GreaterThanOrEqual, LessThanOrEqual, Like, Not, Between, InList, And, Or, Cast, BitwiseAnd, BitwiseOr and TypeOf. Support of more complex filters is optional. This Facet has been updated to include several optional Base Information ConformanceUnits. These ConformanceUnits are optional to allow for backward compatibility, in the future these optional ConformanceUnits will become required, and so it is highly recommended that all servers support them. | X | Yes | |
| Auditing Server Facet | This Facet requires the support of Auditing which includes the Standard Event Subscription Server Facet. Support of this Facet requires that Audit Events be produced when a client performs some action to change the state of the server, such as changing the AddressSpace, inserting or updating a value etc. The auditEntryId passed by the Client is a field contained in every Audit Event and allows actions to be traced across multiple systems. The Audit Event Types and their fields must be exposed in the Server’s AddressSpace Note: Auditing Server Facet is supported but Compliance Test Tool doesn’t support any test cases for this. | X | Yes | |
| Request State Change Server Facet | This Facet specifies the support of the RequestServerStateChange Method. | X | No | |
| Address Space Notifier Server Facet | This Facet requires the support of a hierarchy of Object Nodes that are notifiers and Nodes that are event sources. The hierarchy is commonly used to organize a plant into areas that can be managed by different operators. | X | Yes |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| A & C Base Condition Server Facet | This Facet requires basic support for Conditions. Information about Conditions is provided through Event notifications and thus this Facet builds upon the Standard Event Subscription Server Facet. Conditions that are in an “interesting” state (as defined by the Server) can be refreshed using the Refresh Method, which requires support for the Method Server Facet. Optionally the server may also provide support for Condition classes | X | Yes | |
| A & C Refresh2 Server Facet | This Facet enhances the A & C Base Condition Server Facet with support of the ConditionRefresh2 Method. | X | No | |
| A & C Address Space Instance Server Facet | This Facet specifies the support required for a Server to expose Alarms and Conditions in its AddressSpace. This includes the A & C AddressSpace information model. | X | Yes | |
| A & C Enable Server Facet | This Facet requires the enabling and disabling of Conditions. This Facet builds upon the A&C Base Condition Server Facet. Enabling and disabling also requires that instances of these ConditionTypes exist in the AddressSpace since the enable Method can only be invoked on an instance of the Condition | X | No | |
| A & C Previous Instances Server Facet | This Facet requires support for Conditions with previous states that still require action on the part of the operator. This Facet builds upon the A&C Base Condition Server Facet. A common use case for this Facet is a safety critical system that requires that all Alarms be acknowledged even if it the original problem goes away and the Alarm returns to the inactive state. In these cases, the previous state with active Alarm is still reported by the Server until the Operator acknowledges it. When a Condition has previous states it will produce events with different Branch identifiers. When previous state no longer needs attention the branch will disappear. | X | No | |
| A & C Acknowledgeable Alarm Server Facet | This Facet requires support for Acknowledgement of active Alarms. This Facet builds upon the A & C Alarm Server Facet. Acknowledgement requires support of the Acknowledge Method and the Acknowledged state. Support of the Confirmed state and the Confirm Method is optional. | X | Yes | |
| A & C Alarm Server Facet | This Facet requires support for Alarms. Alarms extend the ConditionType by adding an Active state which indicates when something in the system requires attention by an Operator. This Facet builds upon the A&C Base Condition Server Facet. This facet requires that discrete AlarmTypes be supported, it also allows for optional support of shelving, alarm comments and other discrete AlarmTypes such as Trip or Off-Normal. | X | No | |
| A & C Exclusive Alarming Server Facet | This Facet requires support for Alarms with multiple sub-states that identify different limit Conditions. This facet builds upon the A&C Alarm Server Facet. The term exclusive means only one sub-state can be active at a time. For example, a temperature exceeds the HighHigh limit the associated exclusive LevelAlarm will be in the HighHigh sub-state and not in the High sub-state. This Facet requires that a Server support at least one of the optional Alarm models: Limit, RateOfChange or Deviation. | X | No | |
| A & C Non-Exclusive Alarming Server Facet | This Facet requires support for Alarms with multiple sub-states that identify different limit Conditions. This Facet builds upon the A&C Alarm Server Facet. The term non-exclusive means more than one sub-state can be active at a time. For example, if a temperature exceeds the HighHigh limit the associated non-exclusive LevelAlarm will be in both the High and the HighHigh sub-state. This Facet requires that a server support at least one of the optional alarm models: Limit, RateOfChange or Deviation. | X | No | |
| A & C AlarmMetrics Server Facet | This Facet requires support for AlarmMetrics. AlarmMetrics expose status and potential issues in the alarm system. A Server can provide these metrics at various levels (operator station, plant area, overall system etc.). | X | No | |
| A & C CertificateExpiration Server Facet | This Facet requires support of the CertificateExpirationAlarmType. It is used to inform Clients when the Server’s Certificate is within the defined expiration period. | X | No | |
| A & C Dialog Server Facet | This Facet requires support of Dialog Conditions. This Facet builds upon the A & C BaseCondition Server Facet Dialogs are ConditionTypes used to request user input. They are typically used when a Server has entered some state that requires intervention by a Client. For example, a Server monitoring a paper machine indicates that a roll of paper has been wound and is ready for inspection. The Server would activate a Dialog Condition indicating to the user that an inspection is required. Once the inspection has taken place the user responds by informing the Server of an accepted or unaccepted inspection allowing the process to continue. | X | No | |
| A & E Wrapper Facet | This Facet specifies the requirements for a UA Server that wraps an OPC Alarm & Event (AE) Server (COM). This Profile identifies the sub-set of the UA Alarm & Condition model which is provided by the COM OPC AE specification. It is intended to provide guidance to developers who are creating servers that front-end existing applications. It is important to note that some OPC A&E COM Servers may not support all of the functionality provided by an OPC UA A&C server, in these cases similar functionality maybe available via some non-OPC interface. For example, if an A&E COM server does not support sending Alarm Acknowledgement messages to the system that it is obtaining alarm information from, this functionality may be available via some out of scope features in the underlying Alarm system. Another possibility is that the underlying system does not require acknowledgements or automatically acknowledges the alarm. | X | No |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Historical Raw Data Server Facet | This Facet defines the basic functionality when supporting historical data access for raw data. | X | Yes | |
| Historical Data AtTime Server Facet | This Facet indicates that the historical Server supports reading data by specifying specific timestamps. | X | Yes | |
| Historical Aggregate Server Facet | This Facet indicates that the server supports aggregate processing to produce derived values from raw historical data. | X | Yes | |
| Historical Access Modified Data Server Facet | This Facet defines support of reading modified historical values (values that where modified or inserted). | X | No | |
| Historical Annotation Server Facet | This Facet defines support for the storage and retrieval of annotations for historical data. | X | No | |
| Historical Access Structured Data Server Facet | This Facet indicates that the Server supports storage and retrieval of structured values for all supported access types. If a listed access type is supported, then the corresponding optional ConformanceUnit shall be supported. | X | No | |
| Historical Data Update Server Facet | This Facet includes Historical Data Update functionality. | X | No | |
| Historical Data Insert Server Facet | This Facet includes Historical Data Insert functionality. | X | No | |
| Historical Data Replace Server Facet | This Facet includes Historical Data Replace functionality. | X | No | |
| Historical Data Delete Server Facet | This Facet includes Historical Data Delete functionality. | X | No |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Base Historical Event Server Facet | This Facet defines the server requirements to support basic Historical Event functionality, including simple filtering and general access. | X | Yes | |
| Historical Event Update Server Facet | This Facet includes Historical Event update access functionality. | X | No | |
| Historical Event Insert Server Facet | This Facet includes Historical Event insert access functionality. | X | No | |
| Historical Event Replace Server Facet | This Facet includes Historical Event replace access functionality. | X | No | |
| Historical Event Delete Server Facet | This Facet includes Historical Event delete access functionality | X | No |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Aggregate Subscription Server Facet | This Facet defines the handling of the aggregate filter when subscribing for Attribute values. | X | No |
| Profile | Description | UaCore 1.04 | UaCore 1.05 | Supported |
|---|---|---|---|---|
| Client Redundancy Server Facet | This Facet defines the Server actions that are required for support of redundant Clients. Support of this Facet requires the implementation of the TransferSubscriptions Service which allows the transfer of Subscriptions from one Client’s Session to another Client’s Session. | X | No | |
| Redundancy Transparent Server Facet | This Facet requires support for transparent redundancy. If Servers implement transparent redundancy, then the failover from one Server to another is transparent to the Client such that the Client is unaware that a failover has occurred; the Client does not need to do anything at all to keep data flowing. This type of redundancy is usually a hardware solution. | X | No | |
| Redundancy Visible Server Facet | This Facet specifies the support for non-transparent redundancy. Failover for this type of redundancy requires the Client to monitor Server status and to switch to a backup Server if it detects a failure. The Server shall expose the methods of failover it supports (cold, warm or hot). The failover method tells the Client what it must do when connecting to a Server and when a failure occurs. Cold redundancy requires a Client to reconnect to a backup Server after the initial Server has failed. Warm redundancy allows a Client to connect to multiple Servers, but only one Server will be providing values. In hot redundancy multiple Servers are able to provide data and a Client can connect to multiple Servers for the data. | X | No |