Errata exists for this version of the document.

OPC UA Services are divided into Service Sets, each defining a logical grouping of Services used to access a particular aspect of the Server. The Service Sets are described below. The Service Sets and their Services are specified in Part 4. Whether or not a Server suorts a Service Set, or a specific Service within a Service Set, is defined by its Profile. Profiles are described in Part 7.

This Service Set defines Services used to discover Servers that are available in a system. It also provides a manner in which clients can read the security configuration required for connection to the Server. The Discovery Services are implemented by individual Servers and by dedicated Discovery Servers. Well known dedicated Discovery Servers provide a way for clients to discover all registered Servers. Part 12 describes how to use the Discovery Services with dedicated Discovery Servers.

This Service Set defines Services used to open a communication channel that ensures the confidentiality and integrity of all Messages exchanged with the Server. The base concepts for UA security are defined in Part 2.

The SecureChannel Services are unlike other Services because they are typically not implemented by the OPC UA Application directly. Instead, they are provided by the communication stack that the OPC UA Application is built on. OPC UA Applications simply need to verify that a SecureChannel is active whenever it receives a Message. Part 6 describes how the SecureChannel Services are implemented with different types of communication stacks.

A SecureChannel is a long-running logical connection between a single Client and a single Server. This channel maintains a set of keys that are known only to the Client and Server and that are used to authenticate and encrypt Messages sent across the network. The SecureChannel Services allow the Client and Server to securely negotiate the keys to use.

The exact algorithms used to authenticate and encrypt Messages are described in the security policies for a Server. These policies are exposed via the Discovery Service Set. A Client selects the appropriate endpoint that supports the desired security policy by the Server when it creates a SecureChannel.

When a Client and Server are communicating via a SecureChannel they verify that all incoming Messages have been signed and/or encrypted according to the security policy. A UA application is expected to ignore any Message that does not conform to the security policy for the channel.

A SecureChannel is separate from the UA Application Session; however, a single UA Application Session may only be accessed via a single SecureChannel. This implies that the UA application is able to determine what SecureChannel is associated with each Message. A communication stack that provides a SecureChannel mechanism but that does not allow the application to know what SecureChannel was used for a given Message cannot be used to implement the SecureChannel Service Set.

The relationship between the UA Application Session and the SecureChannel is illustrated in Figure 9. The UA applications use the communication stack to exchange Messages. First, the SecureChannel Services are used to establish a SecureChannel between the two communication stacks, allowing them to exchange Messages in a secure way. Second, the UA applications use the Session Service Set to establish a UA application Session.

Figure 9 – SecureChannel and Session Services

This Service Set defines Services used to establish an application-layer connection in the context of a Session on behalf of a specific user.

The NodeManagement Service Set allows Clients to add, modify, and delete Nodes in the AddressSpace. These Services provide an interface for the configuration of Servers.

Views are publicly defined, Server-created subsets of the AddressSpace. The entire AddressSpace is the default View, and therefore, the View Services are capable of operating on the entire AddressSpace. Future versions of this specification may also define Services to create Client defined Views.

The View Service Set allows Clients to discover Nodes in a View by browsing. Browsing allows Clients to navigate up and down the hierarchy, or to follow References between Nodes contained in the View. In this manner, browsing also allows Clients to discover the structure of the View.

The Query Service Set allows users to access the address space without browsing and without knowledge of the logical schema used for internal storage of the data.

Querying allows Clients to select a subset of the Nodes in a View based on some Client-provided filter criteria. The Nodes selected from the View by the query statement are called a result set.

Servers may find it difficult to process queries that require access to runtime data, such as device data, that involves resource intensive operations or significant delays. In these cases, the Server may find it necessary to reject the query.

The Attribute Service Set is used to read and write Attribute values. Attributes are primitive characteristics of Nodes that are defined by OPC UA. They may not be defined by Clients or Servers. Attributes are the only elements in the AddressSpace permitted to have data values. A special Attribute, the Value Attribute is used to define the value of Variables.

Methods represent the function calls of Objects. They are defined in Part 3. Methods are invoked and return after completion, whether successful or unsuccessful. Execution times for Methods may vary, depending on the function they are performing.

The Method Service Set defines the means to invoke Methods. A Method is always a component of an Object. Discovery is provided through the browse and query Services. Clients discover the Methods supported by a Server by browsing for the owning Objects that identify their supported Methods.

Because Methods may control some aspect of plant operations, method invocation may depend on environmental or other conditions. This may be especially true when attempting to re-invoke a Method immediately after it has completed execution. Conditions that are required to invoke the Method may not yet have returned to the state that permits the Method to start again. In addition, some Methods may be capable of supporting concurrent invocations, while others may have a single invocation executing at a given time.

The MonitoredItem Service Set is used by the Client to create and maintain MonitoredItems. MonitoredItems monitor Variables, Attributes and EventNotifiers. They generate Notifications when they detect certain conditions. They monitor Variables for a change in value or status; Attributes for a change in value; and EventNotifiers for newly generated Alarm and Event reports.

Each MonitoredItem identifies the item to monitor and the Subscription to use to periodically publish Notifications to the Client (see 7.11). Each MonitoredItem also specifies the rate at which the item is to be monitored (sampled) and, for Variables and EventNotifiers, the filter criteria used to determine when a Notification is to be generated. Filter criteria for Attributes are specified by their Attribute definitions in Part 4.

The sample rate defined for a MonitoredItem may be faster than the publishing rate of the Subscription. For this reason, the MonitoredItem may be configured to either queue all Notifications or to queue only the latest Notification for transfer by the Subscription. In this latter case, the queue size is one.

MonitoredItem Services also define a monitoring mode. The monitoring mode is configured to disable sampling and reporting, to enable sampling only, or to enable both sampling and reporting. When sampling is enabled, the Server samples the item. In addition, each sample is evaluated to determine if a Notification should be generated. If so, the Notification is queued. If reporting is enabled, the queue is made available to the Subscription for transfer.

Finally, MonitoredItems can be configured to trigger the reporting of other MonitoredItems. In this case, the monitoring mode of the items to report is typically set to sampling only, and when the triggering item generates a Notification, any queued Notifications of the items to report are made available to the Subscription for transfer.

The Subscription Service Set is used by the Client to create and maintain Subscriptions. Subscriptions are entities that periodically publish NotificationMessages for the MonitoredItem assigned to them (see 7.9). The NotificationMessage contains a common header followed by a series of Notifications. The format of Notifications is specific to the type of item being monitored (i.e. Variables, Attributes, and EventNotifiers).

Once created, the existence of a Subscription is independent of the Client’s Session with the Server. This allows one Client to create a Subscription, and a second, possibly a redundant Client, to receive NotificationMessages from it.

To protect against non-use by Clients, Subscriptions have a configured lifetime that Clients periodically renew. If any Client fails to renew the lifetime, the lifetime expires and the Subscription is closed by the Server. When a Subscription is closed, all MonitoredItems assigned to the Subscription are deleted.

Subscriptions include features that support detection and recovery of lost Messages. Each NotificationMessage contains a sequence number that allows Clients to detect missed Messages. When there are no Notifications to send within the keep-alive time interval, the Server sends a keep-alive Message that contains the sequence number of the next NotificationMessage sent. If a Client fails to receive a Message after the keep-alive interval has expired, or if it determines that it has missed a Message, it can request the Server to resend one or more Messages.

___________