Subscriptionsare used to report Notificationsto the Client. Their general behaviour is summarized below. Their precise behaviour is described in 5.13.1.2.

  1. Subscriptionshave a set of MonitoredItemsassigned to them by the Client. MonitoredItemsgenerate Notificationsthat are to be reported to the Clientby the Subscription(see 5.12.1for a description of MonitoredItems).
  2. Subscriptionshave a publishing interval. The publishing interval of a Subscriptiondefines the cyclic rate at which the Subscriptionexecutes. Each time it executes, it attempts to send a NotificationMessageto the Client. NotificationMessagescontain Notificationsthat have not yet been reported to Client.
  3. NotificationMessagesare sent to the Clientin response to Publishrequests. Publishrequests are normally queued to the Session as they are received, and one is de-queued and processed by a Subscriptionrelated to this Sessionfor each publishing cycle, if there are Notificationsto report. When there are not, the Publishrequest is not de-queued from the Session, and the Serverwaits until the next cycle and checks again for Notifications.
  4. At the beginning of a cycle, if there are Notificationsto send but there are no Publishrequests queued, the Serverenters a wait state for a Publishrequest to be received. When one is received, it is processed immediately without waiting for the next publishing cycle.
  5. NotificationMessagesare uniquely identified by sequence numbers that enable Clientsto detect missed Messages. The publishing interval also defines the default sampling interval for its MonitoredItems.
  6. Subscriptionshave a keep-alive counter that counts the number of consecutive publishing cycles in which there have been no Notificationsto report to the Client. When the maximum keep-alive count is reached, a Publishrequest is de-queued and used to return a keep-alive Message. This keep-alive Messageinforms the Clientthat the Subscriptionis still active. Each keep-alive Messageis a response to a Publishrequest in which the notificationMessageparameter does not contain any Notificationsand that contains the sequence number of the next NotificationMessagethat is to be sent. In the clauses that follow, the term NotificationMessagerefers to a response to a Publishrequest in which the notificationMessageparameter actually contains one or more Notifications, as opposed to a keep-alive Messagein which this parameter contains no Notifications. The maximum keep-alive count is set by the Clientduring Subscriptioncreation and may be subsequently modified using the ModifySubscription Service. Similar to Notificationprocessing described in (c) above, if there are no Publishrequests queued, the Serverwaits for the next one to be received and sends the keep-alive immediately without waiting for the next publishing cycle.
  7. Publishing by a Subscriptionmay be enabled or disabled by the Clientwhen created, or subsequently using the SetPublishingMode Service. Disabling causes the Subscriptionto cease sending NotificationMessagesto the Client. However, the Subscriptioncontinues to execute cyclically and continues to send keep-alive Messagesto the Client.
  8. Subscriptionshave a lifetime counter that counts the number of consecutive publishing cycles in which there have been no Publishrequests available to send a Publishresponse for the Subscription. Any Servicecall that uses the SubscriptionIdor the processing of a Publishresponse resets the lifetime counter of this Subscription. When this counter reaches the value calculated for the lifetime of a Subscriptionbased on the MaxKeepAliveCount parameter in the CreateSubscription Service(5.13.2), the Subscriptionis closed. Closing the Subscriptioncauses its MonitoredItemsto be deleted. In addition the Servershall issue a StatusChangeNotification notificationMessagewith the status code Bad_Timeout. The StatusChangeNotification notificationMessagetype is defined in 7.25.4.
  9. Sessionsmaintain a retransmission queue of sent NotificationMessages. NotificationMessagesare retained in this queue until they are acknowledged. The Sessionshall maintain a retransmission queue size of at least two times the number of Publishrequests per Sessionthe Serversupports. A Profilein OPC 10000-7may make the retransmission queue support optional. The minimum number of Publishrequests per Sessionthe Servershall support is defined in OPC 10000-7. Clientsare required to acknowledge NotificationMessagesas they are received if the Publishresponse parameter availableSequenceNumbersis not an empty array. An empty array in availableSequenceNumbersindicates that the Serverdoes not support a retransmission queue and acknowledgement of NotificationMessages. In the case of a retransmission queue overflow, the oldest sent NotificationMessagegets deleted. If a Subscriptionis transferred to another Session, the queued NotificationMessagesfor this Subscriptionare moved from the old to the new Session.

The sequence number is an unsigned 32-bit integer that is incremented by one for each NotificationMessagesent. The value 0 is never used for the sequence number. The first NotificationMessagesent on a Subscriptionhas a sequence number of 1. If the sequence number rolls over, it rolls over to 1.

When a Subscriptionis created, the first Messageis sent at the end of the first publishing cycle to inform the Clientthat the Subscriptionis operational. A NotificationMessageis sent if there are Notificationsready to be reported. If there are none, a keep-alive Messageis sent instead that contains a sequence number of 1, indicating that the first NotificationMessagehas not yet been sent. This is the only time a keep-alive Messageis sent without waiting for the maximum keep-alive count to be reached, as specified in (f) above.

A Clientshall be prepared for receiving Publishresponses for a Subscriptionmore frequently than the corresponding publishing interval. One example is the situation where the number of available notifications exceeds the Subscriptionsetting maxNotificationsPerPublish. A Clientis always able to control the timing of the Publishresponses by not queueing Publishrequests. If a Clientdoes not queue Publishrequests in the Server, the Servercan only send a Publishresponse if it receives a new Publishrequest. This would increase latency for delivery of notifications but allows a Clientto throttle the number of received Publishresponses in high load situations.

The value of the sequence number is never reset during the lifetime of a Subscription. Therefore, the same sequence number shall not be reused on a Subscriptionuntil over four billion NotificationMessageshave been sent. At a continuous rate of one thousand NotificationMessagesper second on a given Subscription, it would take roughly fifty days for the same sequence number to be reused. This allows Clientsto safely treat sequence numbers as unique.

Sequence numbers are also used by Clientsto acknowledge the receipt of NotificationMessages. Publishrequests allow the Clientto acknowledge all Notificationsup to a specific sequence number and to acknowledge the sequence number of the last NotificationMessagereceived. One or more gaps may exist in between. Acknowledgements allow the Serverto delete NotificationMessagesfrom its retransmission queue.

Clientsmay ask for retransmission of selected NotificationMessagesusing the Republish Service. This Servicereturns the requested Message.

Subscriptionsare designed to work independent of the actual communication connection between OPC UA Clientand Serverand independent of a Session. Short communication interruptions can be handled without losing data or events. To make sure that longer communication interruptions or planned disconnects can be handled without losing data or events, an OPC UA Servermay support durable Subscriptions. If this feature is supported, the Serveraccepts a high Subscription RequestedLifetimeCountand large MonitoredItem QueueSizeparameter settings. Subclause 6.8describes how durable Subscriptionscan be created and used.

The state table formally describes the operation of the Subscription. The following model of operations is described by this state table. This description applies when publishing is enabled or disabled for the Subscription.

After creation of the Subscription, the Serverstarts the publishing timer and restarts it whenever it expires. If the timer expires the number of times defined for the Subscriptionlifetime without having received a Subscription Servicerequest from the Client, the Subscriptionassumes that the Clientis no longer present, and terminates.

Clientssend Publishrequests to Serversto receive Notifications. Publishrequests are not directed to any one Subscriptionand, therefore, may be used by any Subscription. Each contains acknowledgements for one or more Subscriptions. These acknowledgements are processed when the Publishrequest is received. The Serverthen queues the request in a queue shared by all Subscriptions, except in the following cases.

  1. The previous Publishresponse indicated that there were still more Notificationsready to be transferred and there were no more Publishrequests queued to transfer them.
  2. The publishing timer of a Subscriptionexpired and there were either Notificationsto be sent or a keep-alive Messageto be sent.

In these cases, the newly received Publishrequest is processed immediately by the first Subscriptionto encounter either case (a) or case (b).

Each time the publishing timer expires, it is immediately reset. If there are Notificationsor a keep-alive Messageto be sent, it de-queues and processes a Publishrequest. When a Subscriptionprocesses a Publishrequest, it accesses the queues of its MonitoredItemsand de-queues its Notifications, if any. It returns these Notificationsin the response, setting the moreNotificationsflag if it was not able to return all available Notificationsin the response.

If there were Notificationsor a keep-alive Messageto be sent but there were no Publishrequests queued, the Subscriptionassumes that the Publishrequest is late and waits for the next Publishrequest to be received, as described in case (b).

If the Subscriptionis disabled when the publishing timer expires or if there are no Notificationsavailable, it enters the keep-alive state and sets the keep-alive counter to its maximum value as defined for the Subscription.

While in the keep-alive state, it checks for Notificationseach time the publishing timer expires. If one or more Notificationshave been generated, a Publishrequest is de-queued and a NotificationMessageis returned in the response. However, if the publishing timer expires without a Notificationbecoming available, a Publishrequest is de-queued and a keep-alive Messageis returned in the response. The Subscriptionthen returns to the normal state of waiting for the publishing timer to expire again. If, in either of these cases, there are no Publishrequests queued, the Subscriptionwaits for the next Publishrequest to be received, as described in case (b).

The Subscriptionstates are defined in Table 84.

Table 84– Subscription States

State

Description

CLOSED

The Subscriptionhas not yet been created or has terminated.

CREATING

The Subscriptionis being created.

NORMAL

The Subscriptionis cyclically checking for Notificationsfrom its MonitoredItems. The keep-alive counter is not used in this state.

LATE

The publishing timer has expired and there are Notificationsavailable or a keep-alive Messageis ready to be sent, but there are no Publishrequests queued. When in this state, the next Publishrequest is processed when it is received. The keep-alive counter is not used in this state.

KEEPALIVE

The Subscriptionis cyclically checking for Notificationsfrom its MonitoredItemsor for the keep-alive counter to count down to 0 from its maximum.

The state table is described in Table 85. The following rules and conventions apply.

  1. Eventsrepresent the receipt of Servicerequests and the occurrence internal Events, such as timer expirations.
  2. Servicerequests Eventsmay be accompanied by conditions that test Serviceparameter values. Parameter names begin with a lower case letter.
  3. Internal Eventsmay be accompanied by conditions that test state Variablevalues. State Variablesare defined in 5.13.1.3. They begin with an upper case letter.
  4. Servicerequest and internal Eventsmay be accompanied by conditions represented by functions whose return value is tested. Functions are identified by “()” after their name. They are described in 5.13.1.4.
  5. When an Eventis received, the first transition for the current state is located and the transitions are searched sequentially for the first transition that meets the Eventor conditions criteria. If none are found, the Eventis ignored.
  6. Actions are described by functions and state Variablemanipulations.
  7. The LifetimeTimerExpires Eventis triggered when its corresponding counter reaches zero.

Table 85– Subscription State Table

#

Current State

Event/Conditions

Action

Next State

1

CLOSED

Receive CreateSubscription Request

CreateSubscription()

CREATING

2

CREATING

CreateSubscription fails

ReturnNegativeResponse()

CLOSED

3

CREATING

CreateSubscription succeeds

InitializeSubscription()

MessageSent = FALSE

ReturnResponse()

NORMAL

4

NORMAL

Receive PublishRequest

&&

(

PublishingEnabled == FALSE

||

(PublishingEnabled == TRUE

&& MoreNotifications == FALSE)

)

DeleteAckedNotificationMsgs()

EnqueuePublishingReq()

NORMAL

5

NORMAL

Receive PublishRequest

&& PublishingEnabled == TRUE

&& MoreNotifications == TRUE

ResetLifetimeCounter()

DeleteAckedNotificationMsgs()

ReturnNotifications()

MessageSent = TRUE

NORMAL

6

NORMAL

PublishingTimer Expires

&& PublishingReqQueued == TRUE

&& PublishingEnabled == TRUE

&& NotificationsAvailable == TRUE

ResetLifetimeCounter()

StartPublishingTimer()

DequeuePublishReq()

ReturnNotifications()

MessageSent == TRUE

NORMAL

7

NORMAL

PublishingTimer Expires

&& PublishingReqQueued == TRUE

&& MessageSent == FALSE

&&

(

PublishingEnabled == FALSE

||

(PublishingEnabled == TRUE

&& NotificationsAvailable == FALSE)

)

ResetLifetimeCounter()

StartPublishingTimer()

DequeuePublishReq()

ReturnKeepAlive()

MessageSent == TRUE

NORMAL

8

NORMAL

PublishingTimer Expires

&& PublishingReqQueued == FALSE

&&

(

MessageSent == FALSE

||

(PublishingEnabled == TRUE

&& NotificationsAvailable == TRUE)

)

StartPublishingTimer()

LATE

9

NORMAL

PublishingTimer Expires

&& MessageSent == TRUE

&&

(

PublishingEnabled == FALSE

||

(PublishingEnabled == TRUE

&& NotificationsAvailable == FALSE)

)

StartPublishingTimer()

ResetKeepAliveCounter()

KeepAliveCounter--

KEEPALIVE

10

LATE

Receive PublishRequest

&& PublishingEnabled == TRUE

&& (NotificationsAvailable == TRUE

|| MoreNotifications == TRUE)

ResetLifetimeCounter()

DeleteAckedNotificationMsgs()

ReturnNotifications()

MessageSent = TRUE

NORMAL

11

LATE

Receive PublishRequest

&&

(

PublishingEnabled == FALSE

||

(PublishingEnabled == TRUE

&& NotificationsAvailable == FALSE

&& MoreNotifications == FALSE)

)

ResetLifetimeCounter()

DeleteAckedNotificationMsgs()

ReturnKeepAlive()

MessageSent = TRUE

KEEPALIVE

12

LATE

PublishingTimer Expires

StartPublishingTimer()

LATE

13

KEEPALIVE

Receive PublishRequest

DeleteAckedNotificationMsgs()

EnqueuePublishingReq()

KEEPALIVE

14

KEEPALIVE

PublishingTimer Expires

&& PublishingEnabled == TRUE

&& NotificationsAvailable == TRUE

&& PublishingReqQueued == TRUE

ResetLifetimeCounter()

StartPublishingTimer()

DequeuePublishReq()

ReturnNotifications()

MessageSent == TRUE

NORMAL

15

KEEPALIVE

PublishingTimer Expires

&& PublishingReqQueued == TRUE

&& KeepAliveCounter <= 1

&&

(

PublishingEnabled == FALSE

||

(PublishingEnabled == TRUE

&& NotificationsAvailable == FALSE

)

StartPublishingTimer()

DequeuePublishReq()

ReturnKeepAlive()

ResetKeepAliveCounter()

KEEPALIVE

16

KEEPALIVE

PublishingTimer Expires

&& KeepAliveCounter > 1

&&

(

PublishingEnabled == FALSE

||

(PublishingEnabled == TRUE

&& NotificationsAvailable == FALSE)

)

StartPublishingTimer()

KeepAliveCounter--

KEEPALIVE

17

KEEPALIVE

PublishingTimer Expires

&& PublishingReqQueued == FALSE

&&

(

KeepAliveCounter == 1

||

(KeepAliveCounter > 1

&& PublishingEnabled == TRUE

&& NotificationsAvailable == TRUE)

)

StartPublishingTimer()

LATE

18

NORMAL

|| LATE

|| KEEPALIVE

Receive ModifySubscription Request

ResetLifetimeCounter()

UpdateSubscriptionParams()

ReturnResponse()

SAME

19

NORMAL

|| LATE

|| KEEPALIVE

Receive SetPublishingMode Request

ResetLifetimeCounter()

SetPublishingEnabled()

MoreNotifications = FALSE

ReturnResponse()

SAME

20

NORMAL

|| LATE

|| KEEPALIVE

Receive Republish Request

&& RequestedMessageFound == TRUE

ResetLifetimeCounter()

ReturnResponse()

SAME

21

NORMAL

|| LATE

|| KEEPALIVE

Receive Republish Request

&& RequestedMessageFound == FALSE

ResetLifetimeCounter()

ReturnNegativeResponse()

SAME

22

NORMAL

|| LATE

|| KEEPALIVE

Receive TransferSubscriptions Request

&& SessionChanged() == FALSE

ResetLifetimeCounter()

ReturnNegativeResponse ()

SAME

23

NORMAL

|| LATE

|| KEEPALIVE

Receive TransferSubscriptions Request

&& SessionChanged() == TRUE

&& ClientValidated() ==TRUE

SetSession()

ResetLifetimeCounter()

ReturnResponse()

IssueStatusChangeNotification()

SAME

24

NORMAL

|| LATE

|| KEEPALIVE

Receive TransferSubscriptions Request

&& SessionChanged() == TRUE

&& ClientValidated() == FALSE

ReturnNegativeResponse()

SAME

25

NORMAL

|| LATE

|| KEEPALIVE

Receive DeleteSubscriptions Request

&& SubscriptionAssignedToClient ==TRUE

DeleteMonitoredItems()

DeleteClientPublReqQueue()

CLOSED

26

NORMAL

|| LATE

|| KEEPALIVE

Receive DeleteSubscriptions Request

&& SubscriptionAssignedToClient ==FALSE

ResetLifetimeCounter()

ReturnNegativeResponse()

SAME

27

NORMAL

|| LATE

|| KEEPALIVE

LifetimeCounter == 1

The LifetimeCounter is decremented if PublishingTimer expires and PublishingReqQueued == FALSE

The LifetimeCounter is reset if PublishingReqQueued == TRUE.

DeleteMonitoredItems()

IssueStatusChangeNotification()

CLOSED

The state variables are defined alphabetically in Table 86.

Table 86– State variables and parameters

State Variable

Description

MoreNotifications

A boolean value that is set to TRUE only by the CreateNotificationMsg() when there were too many Notificationsfor a single NotificationMessage.

LatePublishRequest

A boolean value that is set to TRUE to reflect that, the last time the publishing timer expired, there were no Publishrequests queued.

LifetimeCounter

A value that contains the number of consecutive publishing timer expirations without Clientactivity before the Subscriptionis terminated.

MessageSent

A boolean value that is set to TRUE to mean that either a NotificationMessageor a keep-alive Messagehas been sent on the Subscription. It is a flag that is used to ensure that either a NotificationMessageor a keep-alive Messageis sent out the first time the publishing timer expires.

NotificationsAvailable

A boolean value that is set to TRUE only when there is at least one MonitoredItemthat is in the reporting mode and that has a Notificationqueued or there is at least one item to report whose triggering item has triggered and that has a Notificationqueued. The transition of this state Variablefrom FALSE to TRUE creates the “New NotificationQueued” Eventin the state table.

PublishingEnabled

The parameter that requests publishing to be enabled or disabled.

PublishingReqQueued

A boolean value that is set to TRUE only when there is a Publishrequest Messagequeued to the Subscription.

RequestedMessageFound

A boolean value that is set to TRUE only when the Messagerequested to be retransmitted was found in the retransmission queue.

SeqNum

The value that records the value of the sequence number used in NotificationMessages.

SubscriptionAssignedToClient

A boolean value that is set to TRUE only when the Subscriptionrequested to be deleted is assigned to the Clientthat issued the request. A Subscriptionis assigned to the Clientthat created it. That assignment can only be changed through successful completion of the TransferSubscriptions Service.

The action functions are defined alphabetically in Table 87.

Table 87– Functions

Function

Description

ClientValidated()

A boolean function that returns TRUE only when the Clientthat is submitting a TransferSubscriptions request is operating on behalf of the same user and supports the same Profilesas the Clientof the previous Session.

CreateNotificationMsg()

Increment the SeqNum and create a NotificationMessagefrom the MonitoredItemsassigned to the Subscription.

Save the newly-created NotificationMessagein the retransmission queue.

If all available Notificationscan be sent in the Publishresponse, the MoreNotifications state Variableis set to FALSE. Otherwise, it is set to TRUE.

CreateSubscription()

Attempt to create the Subscription.

DeleteAckedNotificationMsgs()

Delete the NotificationMessagesfrom the retransmission queue that were acknowledged by the request.

DeleteClientPublReqQueue()

Clear the Publishrequest queue for the Clientthat is sending the DeleteSubscriptions request, if there are no more Subscriptionsassigned to that Client.

DeleteMonitoredItems()

Delete all MonitoredItemsassigned to the Subscription.

DequeuePublishReq()

De-queue a publishing request in first-in first-out order.

Validate if the publish request is still valid by checking the timeoutHint in the RequestHeader.

If the request timed out, send a Bad_Timeoutservice result for the request and de-queue another publish request.

ResetLifetimeCounter()

EnqueuePublishingReq()

Enqueue the publishing request.

InitializeSubscription()

ResetLifetimeCounter()

MoreNotifications = FALSE

PublishRateChange = FALSE

PublishingEnabled = value of publishingEnabled parameter in the CreateSubscription request

PublishingReqQueued = FALSE

SeqNum = 0

SetSession()

StartPublishingTimer()

IssueStatusChangeNotification()

Issue a StatusChangeNotification notificationMessagewith a status code for the status change of the Subscription. The StatusChangeNotification notificationMessagetype is defined in 7.25.4. Bad_Timeout status code is used if the lifetime expires and Good_SubscriptionTransferred is used if the Subscriptionswas transferred to another Session.

ResetKeepAliveCounter()

Reset the keep-alive counter to the maximum keep-alive count of the Subscription. The maximum keep-alive count is set by the Clientwhen the Subscriptionis created and may be modified using the ModifySubscription Service.

ResetLifetimeCounter()

Reset the LifetimeCounter Variableto the value specified for the lifetime of a Subscriptionin the CreateSubscription Service(5.13.2).

ReturnKeepAlive()

CreateKeepAliveMsg()

ReturnResponse()

ReturnNegativeResponse ()

Return a Serviceresponse indicating the appropriate Servicelevel error. No parameters are returned other than the responseHeader that contains the Servicelevel StatusCode.

ReturnNotifications()

CreateNotificationMsg()

ReturnResponse()

If (MoreNotifications == TRUE) && (PublishingReqQueued == TRUE)

{

DequeuePublishReq()

Loop through this function again

}

ReturnResponse()

Return the appropriate response, setting the appropriate parameter values and StatusCodesdefined for the Service.

SessionChanged()

A boolean function that returns TRUE only when the Sessionused to send a TransferSubscriptions request is different from the Client Sessioncurrently associated with the Subscription.

SetPublishingEnabled ()

Set the PublishingEnabled state Variableto the value of the publishingEnabled parameter received in the request.

SetSession

Set the Sessioninformation for the Subscriptionto match the Sessionon which the TransferSubscriptions request was issued.

StartPublishingTimer()

Start or restart the publishing timer and decrement the LifetimeCounter Variable.

UpdateSubscriptionParams()

Negotiate and update the Subscriptionparameters. If the new keep-alive interval is less than the current value of the keep-alive counter, perform ResetKeepAliveCounter() and ResetLifetimeCounter().

This Serviceis used to create a Subscription. Subscriptionsmonitor a set of MonitoredItemsfor Notificationsand return them to the Clientin response to Publishrequests.

Illegal request values for parameters that can be revised do not generate errors. Instead the Serverwill choose default values and indicate them in the corresponding revised parameter.

Table 88defines the parameters for the Service.

Table 88– CreateSubscription Service Parameters

Name

Type

Description

Request

requestHeader

Request Header

Common request parameters (see 7.33for RequestHeaderdefinition).

requestedPublishing

Interval

Duration

This interval defines the cyclic rate that the Subscriptionis being requested to return Notificationsto the Client. This interval is expressed in milliseconds. This interval is represented by the publishing timer in the Subscriptionstate table (see 5.13.1.2).

The negotiated value for this parameter returned in the response is used as the default sampling interval for MonitoredItemsassigned to this Subscription.

If the requested value is 0 or negative, the Servershall revise with the fastest supported publishing interval.

requestedLifetimeCount

Counter

Requested lifetime count (see 7.8for Counterdefinition). The lifetime count shall be a minimum of three times the keep keep-alive count.

When the publishing timer has expired this number of times without a Publishrequest being available to send a NotificationMessage, then the Subscriptionshall be deleted by the Server.

requestedMaxKeepAlive

Count

Counter

Requested maximum keep-alive count (see 7.8for Counterdefinition). When the publishing timer has expired this number of times without requiring any NotificationMessageto be sent, the Subscriptionsends a keep-alive Messageto the Client.

The negotiated value for this parameter is returned in the response.

If the requested value is 0, the Servershall revise with the smallest supported keep-alive count.

maxNotificationsPerPublish

Counter

The maximum number of notifications that the Clientwishes to receive in a single Publishresponse. A value of zero indicates that there is no limit.

The number of notifications per Publishis the sum of monitoredItems in the DataChangeNotification and events in the EventNotificationList.

publishingEnabled

Boolean

A Booleanparameter with the following values:

TRUEpublishing is enabled for the Subscription.

FALSEpublishing is disabled for the Subscription.

The value of this parameter does not affect the value of the monitoring mode Attributeof MonitoredItems.

priority

Byte

Indicates the relative priority of the Subscription. When more than one Subscriptionneeds to send Notifications, the Servershould de-queue a Publish request to the Subscriptionwith the highest prioritynumber. For Subscriptionswith equal prioritythe Servershould de-queue Publish requests in a round-robin fashion.

A Clientthat does not require special priority settings should set this value to zero.

Response

responseHeader

Response Header

Common response parameters (see 7.34for ResponseHeaderdefinition).

subscriptionId

IntegerId

The Server-assigned identifier for the Subscription(see 7.19for IntegerIddefinition). This identifier shall be unique for the entire Server, not just for the Session, in order to allow the Subscriptionto be transferred to another Sessionusing the TransferSubscriptions service.

After Serverstart-up the generation of subscriptionIdsshould start from a random IntegerIdor continue from the point before the restart.

revisedPublishingInterval

Duration

The actual publishing interval that the Serverwill use, expressed in milliseconds. The Servershould attempt to honour the Clientrequest for this parameter, but may negotiate this value up or down to meet its own constraints.

revisedLifetimeCount

Counter

The lifetime of the Subscriptionshall be a minimum of three times the keep-alive interval negotiated by the Server.

revisedMaxKeepAliveCount

Counter

The actual maximum keep-alive count (see 7.8for Counterdefinition). The Servershould attempt to honour the Clientrequest for this parameter, but may negotiate this value up or down to meet its own constraints.

Table 89defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 89– CreateSubscription Service Result Codes

Symbolic Id

Description

Bad_TooManySubscriptions

The Serverhas reached its maximum number of Subscriptions.

This Serviceis used to modify a Subscription.

Illegal request values for parameters that can be revised do not generate errors. Instead the Serverwill choose default values and indicate them in the corresponding revised parameter.

Changes to the Subscriptionsettings shall be applied immediately by the Server. They take effect as soon as practical but not later than twice the new revisedPublishingInterval.

Table 90defines the parameters for the Service.

Table 90– ModifySubscription Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters (see 7.33for RequestHeaderdefinition).

subscriptionId

IntegerId

The Server-assigned identifier for the Subscription(see 7.19for IntegerIddefinition).

requestedPublishingInterval

Duration

This interval defines the cyclic rate at which the Subscriptionis being requested to return Notificationsto the Client. This interval is expressed in milliseconds. This interval is represented by the publishing timer in the Subscriptionstate table (see 5.13.1.2).

The negotiated value for this parameter returned in the response is used as the default sampling interval for MonitoredItemsassigned to this Subscription.

If the requested value is 0 or negative, the Servershall revise with the fastest supported publishing interval.

requestedLifetimeCount

Counter

Requested lifetime count (see 7.8for Counterdefinition). The lifetime count shall be a minimum of three times the keep keep-alive count.

When the publishing timer has expired this number of times without a Publishrequest being available to send a NotificationMessage, then the Subscriptionshall be deleted by the Server.

requestedMaxKeepAliveCount

Counter

Requested maximum keep-alive count (see 7.8for Counterdefinition). When the publishing timer has expired this number of times without requiring any NotificationMessageto be sent, the Subscriptionsends a keep-alive Messageto the Client.

The negotiated value for this parameter is returned in the response.

If the requested value is 0, the Servershall revise with the smallest supported keep-alive count.

maxNotificationsPerPublish

Counter

The maximum number of notifications that the Clientwishes to receive in a single Publishresponse. A value of zero indicates that there is no limit.

priority

Byte

Indicates the relative priority of the Subscription. When more than one Subscriptionneeds to send Notifications, the Servershould de-queue a Publish request to the Subscriptionwith the highest prioritynumber. For Subscriptionswith equal prioritythe Servershould de-queue Publish requests in a round-robin fashion.

A Clientthat does not require special priority settings should set this value to zero.

Response

responseHeader

ResponseHeader

Common response parameters (see 7.34for ResponseHeaderdefinition).

revisedPublishingInterval

Duration

The actual publishing interval that the Serverwill use, expressed in milliseconds. The Servershould attempt to honour the Clientrequest for this parameter, but may negotiate this value up or down to meet its own constraints.

revisedLifetimeCount

Counter

The lifetime of the Subscriptionshall be a minimum of three times the keep-alive interval negotiated by the Server.

revisedMaxKeepAliveCount

Counter

The actual maximum keep-alive count (see 7.8for Counterdefinition). The Servershould attempt to honour the Clientrequest for this parameter, but may negotiate this value up or down to meet its own constraints.

Table 91defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 91– ModifySubscription Service Result Codes

Symbolic Id

Description

Bad_SubscriptionIdInvalid

See Table 182for the description of this result code.

This Serviceis used to enable sending of Notificationson one or more Subscriptions.

Table 92defines the parameters for the Service.

Table 92– SetPublishingMode Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters (see 7.33for RequestHeaderdefinition).

publishingEnabled

Boolean

A Booleanparameter with the following values:

TRUEpublishing of NotificationMessagesis enabled for the Subscription.

FALSEpublishing of NotificationMessagesis disabled for the Subscription.

The value of this parameter does not affect the value of the monitoring mode Attributeof MonitoredItems. Setting this value to FALSE does not discontinue the sending of keep-alive Messages.

subscriptionIds []

IntegerId

List of Server-assigned identifiers for the Subscriptionsto enable or disable (see 7.19for IntegerIddefinition).

Response

responseHeader

ResponseHeader

Common response parameters (see 7.34for ResponseHeaderdefinition).

results []

StatusCode

List of StatusCodesfor the Subscriptionsto enable/disable (see 7.39for StatusCodedefinition). The size and order of the list matches the size and order of the subscriptionIdsrequest parameter.

diagnosticInfos []

DiagnosticInfo

List of diagnostic information for the Subscriptionsto enable/disable (see 7.12for DiagnosticInfo definition). The size and order of the list matches the size and order of the subscriptionIdsrequest parameter. This list is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the request.

Table 93defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 93– SetPublishingMode Service Result Codes

Symbolic Id

Description

Bad_NothingToDo

See Table 182for the description of this result code.

Bad_TooManyOperations

See Table 182for the description of this result code.

Table 94defines values for the resultsparameter that are specific to this Service. Common StatusCodesare defined in Table 183.

Table 94– SetPublishingMode Operation Level Result Codes

Symbolic Id

Description

Bad_SubscriptionIdInvalid

See Table 182for the description of this result code.

This Serviceis used for two purposes. First, it is used to acknowledge the receipt of NotificationMessagesfor one or more Subscriptions. Second, it is used to request the Serverto return a NotificationMessageor a keep-alive Message. Since Publishrequests are not directed to a specific Subscription, they may be used by any Subscription. 5.13.1.2describes the use of the Publish Service.

Clientstrategies for issuing Publishrequests may vary depending on the networking delays between the Clientand the Server. In many cases, the Clientmay wish to issue a Publishrequest immediately after creating a Subscription, and thereafter, immediately after receiving a Publishresponse.

In other cases, especially in high latency networks, the Clientmay wish to pipeline Publishrequests to ensure cyclic reporting from the Server. Pipelining involves sending more than one Publishrequest for each Subscriptionbefore receiving a response. For example, if the network introduces a delay between the Clientand the Serverof 5 seconds and the publishing interval for a Subscriptionis one second, then the Clientshall issue Publishrequests every second instead of waiting for a response to be received before sending the next request.

A Servershould limit the number of active Publishrequests to avoid an infinite number since it is expected that the Publishrequests are queued in the Server. But a Servershall accept more queued Publishrequests than created Subscriptions. It is expected that a Serversupports several Publishrequests per Subscription. When a Serverreceives a new Publishrequest that exceeds its limit it shall de-queue the oldest Publishrequest and return a response with the result set to Bad_TooManyPublishRequests. If a Clientreceives this Serviceresult for a Publishrequest it shall not issue another Publishrequest before one of its outstanding Publishrequests is returned from the Server.

Clientscan limit the size of Publishresponses with the maxNotificationsPerPublishparameter passed to the CreateSubscription Service. However, this could still result in a message that is too large for the Clientor Serverto process. In this situation, the Clientwill find that either the SecureChannelgoes into a fault state and needs to be re-established or the Publishresponse returns an error and calling the Republish Servicealso returns an error. If either situation occurs then the Clientwill shall adjust its message processing limits or the parameters for the Subscription and/or MonitoredItems.

The return diagnostic info setting in the request header of the CreateMonitoredItemsor the last ModifyMonitoredItems Serviceis applied to the Monitored Itemsand is used as the diagnostic information settings when sending Notifications in the Publishresponse.

Table 95defines the parameters for the Service.

Table 95– Publish Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters (see 7.33for RequestHeaderdefinition).

subscription

Acknowledgements []

Subscription Acknowledgement

The list of acknowledgements for one or more Subscriptions. This list may contain multiple acknowledgements for the same Subscription(multiple entries with the same subscriptionId). This structure is defined in-line with the following indented items.

subscriptionId

IntegerId

The Serverassigned identifier for a Subscription(see 7.19for IntegerIddefinition).

sequenceNumber

Counter

The sequence number being acknowledged (see 7.8for Counterdefinition). The Servermay delete the Messagewith this sequence number from its retransmission queue.

Response

responseHeader

ResponseHeader

Common response parameters (see 7.34for ResponseHeaderdefinition).

subscriptionId

IntegerId

The Server-assigned identifier for the Subscriptionfor which Notificationsare being returned (see 7.19for IntegerIddefinition). The value 0 is used to indicate that there were no Subscriptionsdefined for which a response could be sent.

availableSequence

Numbers []

Counter

A list of sequence number ranges that identify unacknowledged NotificationMessagesthat are available for retransmission from the Subscription’s retransmission queue including the sequence number of this response if it is not a keep-alive Message. This list is prepared after processing the acknowledgements in the request (see 7.8for Counterdefinition).

The list shall be empty if the Serverdoes not support the retransmission queue. If the list is empty, the Clientshould not acknowledge sequence numbers.

This information is for diagnostic purpose and Clientsshould log differences to the expected sequence numbers.

moreNotifications

Boolean

A Booleanparameter with the following values:

TRUEthe number of Notificationsthat were ready to be sent could not be sent in a single response.

FALSEall Notificationsthat were ready are included in the response.

notificationMessage

Notification Message

The NotificationMessagethat contains the list of Notifications. The NotificationMessageparameter type is specified in 7.26.

results []

StatusCode

List of results for the acknowledgements (see 7.39for StatusCodedefinition). The size and order of the list matches the size and order of the subscriptionAcknowledgementsrequest parameter.

diagnosticInfos []

DiagnosticInfo

List of diagnostic information for the acknowledgements (see 7.12for DiagnosticInfo definition). The size and order of the list matches the size and order of the subscriptionAcknowledgementsrequest parameter. This list is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the request.

Table 96defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 96– Publish Service Result Codes

Symbolic Id

Description

Bad_TooManyPublishRequests

The Serverhas reached the maximum number of queued Publishrequests.

Bad_NoSubscription

There is no Subscriptionavailable for this session.

Table 97defines values for the resultsparameter that are specific to this Service. Common StatusCodesare defined in Table 183.

Table 97– Publish Operation Level Result Codes

Symbolic Id

Description

Bad_SubscriptionIdInvalid

See Table 182for the description of this result code.

Bad_SequenceNumberUnknown

The sequence number is unknown to the Server.

Good_RetransmissionQueueNotSupported

The Server does not support retransmission queue and acknowledgement of sequence numbers is not available.

This Servicerequests the Subscriptionto republish a NotificationMessagefrom its retransmission queue. If the Serverdoes not have the requested Messagein its retransmission queue, it returns an error response.

See 5.13.1.2for the detail description of the behaviour of this Service.

See 6.7for a description of the issues and strategies regarding reconnect handling and Republish.

Table 98defines the parameters for the Service.

Table 98– Republish Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters (see 7.33for RequestHeaderdefinition).

subscriptionId

IntegerId

The Serverassigned identifier for the Subscriptionto be republished (see 7.19for IntegerIddefinition).

retransmitSequence

Number

Counter

The sequence number of a specific NotificationMessageto be republished (see 7.8for Counterdefinition).

Response

responseHeader

ResponseHeader

Common response parameters (see 7.34for ResponseHeaderdefinition).

notificationMessage

Notification Message

The requested NotificationMessage. The NotificationMessageparameter type is specified in 7.26.

Table 99defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 99– Republish Service Result Codes

Symbolic Id

Description

Bad_SubscriptionIdInvalid

See Table 182for the description of this result code.

Bad_MessageNotAvailable

The requested message is no longer available.

This Serviceis used to transfer a Subscriptionand its MonitoredItemsfrom one Sessionto another. For example, a Clientmay need to reopen a Sessionand then transfer its Subscriptionsto that Session. It may also be used by one Clientto take over a Subscriptionfrom another Clientby transferring the Subscriptionto its Session.

The authenticationTokencontained in the request header identifies the Sessionto which the Subscriptionand MonitoredItemsshall be transferred. The Servershall validate that the Clientof that Sessionis operating on behalf of the same user and that the potentially new Clientsupports the Profilesthat are necessary for the Subscription. If the Clientuses an ANONYMOUSuser token, the Servershall validate if the ApplicationUriis the same for the old and the new Sessionand the MessageSecurityModeis SIGNor SIGNANDENCRYPT. If the Servertransfers the Subscription, it returns the sequence numbers of the NotificationMessagesthat are available for retransmission. The Clientshould acknowledge all Messagesin this list for which it will not request retransmission.

If the Servertransfers the Subscriptionto the new Session, the Servershall issue a StatusChangeNotification notificationMessagewith the status code Good_SubscriptionTransferred to the old Session. The StatusChangeNotification notificationMessagetype is defined in 7.25.4.

Table 100defines the parameters for the Service.

Table 100– TransferSubscriptions Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters (see 7.33for RequestHeaderdefinition).

subscriptionIds []

IntegerId

List of identifiers for the Subscriptionsto be transferred to the new Client(see 7.19for IntegerIddefinition). These identifiers are transferred from the primary Clientto a backup Clientvia external mechanisms.

sendInitialValues

Boolean

A Booleanparameter with the following values:

TRUEthe first Publish response(s) after the TransferSubscriptionscall shall contain the current values of all Monitored Items in the Subscriptionwhere the Monitoring Mode is set to Reporting.If a value is queued for a data MonitoredItem, the next value in the queue is sent in the Publishresponse. If no value is queued for a data MonitoredItem, the last value sent is repeated in the Publishresponse.

FALSEthe first Publish response after the TransferSubscriptions call shall contain only the value changes since the last Publish response was sent.

This parameter only applies to MonitoredItems used for monitoring Attribute changes.

Response

responseHeader

ResponseHeader

Common response parameters (see 7.34for ResponseHeaderdefinition).

results []

TransferResult

List of results for the Subscriptionsto transfer. The size and order of the list matches the size and order of the subscriptionIdsrequest parameter. This structure is defined in-line with the following indented items.

statusCode

StatusCode

StatusCodefor each Subscriptionto be transferred (see 7.39for StatusCodedefinition).

availableSequence

Numbers []

Counter

A list of sequence number ranges that identify NotificationMessagesthat are in the Subscription’s retransmission queue. This parameter is null or empty if the transfer of the Subscriptionfailed. The Countertype is defined in 7.8.

diagnosticInfos []

DiagnosticInfo

List of diagnostic information for the Subscriptionsto transfer (see 7.12for DiagnosticInfo definition). The size and order of the list matches the size and order of the subscriptionIdsrequest parameter. This list is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the request.

Table 101defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 101– TransferSubscriptions Service Result Codes

Symbolic Id

Description

Bad_NothingToDo

See Table 182for the description of this result code.

Bad_TooManyOperations

See Table 182for the description of this result code.

Bad_InsufficientClientProfile

The Clientof the current Sessiondoes not support one or more Profilesthat are necessary for the Subscription.

Table 102defines values for the operation level statusCodeparameter that are specific to this Service. Common StatusCodesare defined in Table 183.

Table 102– TransferSubscriptions Operation Level Result Codes

Symbolic Id

Description

Bad_SubscriptionIdInvalid

See Table 182for the description of this result code.

Bad_UserAccessDenied

See Table 182for the description of this result code.

The Clientof the current Sessionis not operating on behalf of the same user as the Sessionthat owns the Subscription.

This Serviceis invoked to delete one or more Subscriptionsthat belong to the Client's Session.

Successful completion of this Servicecauses all MonitoredItemsthat use the Subscriptionto be deleted. If this is the last Subscriptionfor the Session, then all Publishrequests still queued for that Sessionare de-queued and shall be returned with Bad_NoSubscription.

Subscriptionsthat were transferred to another Sessionshall be deleted by the Clientthat owns the Session.

Table 103defines the parameters for the Service.

Table 103– DeleteSubscriptions Service Parameters

Name

Type

Description

Request

requestHeader

RequestHeader

Common request parameters (see 7.33for RequestHeaderdefinition).

subscriptionIds []

IntegerId

The Server-assigned identifier for the Subscription(see 7.19for IntegerIddefinition).

Response

responseHeader

ResponseHeader

Common response parameters (see 7.34for ResponseHeaderdefinition).

results []

StatusCode

List of StatusCodesfor the Subscriptionsto delete (see 7.39for StatusCodedefinition). The size and order of the list matches the size and order of the subscriptionIdsrequest parameter.

diagnosticInfos []

DiagnosticInfo

List of diagnostic information for the Subscriptionsto delete (see 7.12for DiagnosticInfo definition). The size and order of the list matches the size and order of the subscriptionIdsrequest parameter. This list is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the request.

Table 104defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 104– DeleteSubscriptions Service Result Codes

Symbolic Id

Description

Bad_NothingToDo

See Table 182for the description of this result code.

Bad_TooManyOperations

See Table 182for the description of this result code.

Table 105defines values for the resultsparameter that are specific to this Service. Common StatusCodesare defined in Table 183.

Table 105– DeleteSubscriptions Operation Level Result Codes

Symbolic Id

Description

Bad_SubscriptionIdInvalid

See Table 182for the description of this result code.