ConditionRefreshallows a Clientto request a Refreshof all Condition instances that currently are in an interesting state (they have the Retainflag set). This includes previous states of a Conditioninstance for which the Servermaintains Branches. A Clientwould typically invoke this Methodwhen it initially connects to a Serverand following any situations, such as communication disruptions, in which it would require resynchronization with the Server. This Methodis only available on the ConditionType. To invoke this Method, the call shall pass the well-known MethodIdof the Methodon the ConditionTypeand the ObjectIdshall be the well-known NodeIdof the ConditionType ObjectType.

Signature

ConditionRefresh(

[in] IntegerId SubscriptionId

);

The parameters are defined in Table 20

Table 20– ConditionRefresh parameters

Argument

Description

SubscriptionId

A valid SubscriptionId of the Subscriptionto be refreshed. The Servershall verify that the SubscriptionIdprovided is part of the Sessionthat is invoking the Method.

Methodresult codes in Table 21(defined in Call Service)

Table 21– ConditionRefresh result codes

Result Code

Description

Bad_SubscriptionIdInvalid

See 10000-4for the description of this result code

Bad_NothingToDo

The ConditionRefresh Methodwas called on a SubscriptionIdthat has no eventMonitoredItems.

Bad_RefreshInProgress

See Table 137for the description of this result code

Bad_UserAccessDenied

The Methodwas not called in the context of the Sessionthat owns the Subscription

See 10000-4for the general description of this result code.

Comments

Sub clause 4.5describes the concept, use cases and information flow in more detail.

The input argument provides a Subscriptionidentifier indicating which Client Subscriptionshall be refreshed. If the Subscriptionis accepted the Serverwill react as follows:

  1. The Serverissues an event of RefreshStartEventType (defined in 5.11.2) marking the start of Refresh.A copy of the instance of RefreshStartEventTypeis queued into the Eventstream for everyNotifier MonitoredItem in the Subscription. Each of the Event copies shall contain the same EventId.
  2. The Serverissues Event Notificationsof any Retained Conditionsand Retained Branchesof Conditionsthat meet the Subscriptionscontent filter criteria. Note that the EventId for such a refreshed Notificationshall be identical to the one for the original Notification, the values of the other Propertiesare Serverspecific, in that some Serversmay be able to replay the exact Eventswith all Properties/Variablesmaintaining the same values as originally sent, but other Serversmight only be able to regenerate the Event. The regenerated Eventmight contain some updated Property/Variablevalues. For example, if the Alarmlimits associated with a Variablewere changed after the generation of the Eventwithout generating a change in the Alarmstate, the new limit might be reported. In another example, if the HighLimit was 100 and the Variableis 120. If the limit were changed to 90 no new Eventwould be generated since no change to the StateMachine, but the limit on a Refreshwould indicate 90, when the original Eventhad indicated 100.
  3. The Servermay intersperse new Event Notificationsthat have not been previously issued to the Notifieralong with those being sent as part of the Refreshrequest. Clientsshall check for multiple Event Notificationsfor a ConditionBranchto avoid overwriting a new state delivered together with an older state from the Refreshprocess.
  4. The Serverissues an instance of RefreshEndEventType(defined in 5.11.3) to signal the end of the Refresh. A copy of the instance of RefreshEndEventTypeis queued into the Eventstream for every Notifier MonitoredItemin the Subscription. Each of the Eventscopies shall contain the same EventId.

It is important to note that if multiple Event Notifiersare in a Subscriptionall Event Notifiersare processed. If a Clientdoes not want all MonitoredItemsrefreshed, then the Clientshould place each MonitoredItemin a separate Subscriptionor call ConditionRefresh2if the Serversupports it.

If more than one Subscriptionis to be refreshed, then the standard call Servicearray processing can be used.

As mentioned above, ConditionRefreshshall also issue Event Notificationsfor prior states if they still need attention. In particular, this is True for Condition instances where previous states still need acknowledgement or confirmation.

Table 22specifies the AddressSpacerepresentation for the ConditionRefresh Method.

Table 22– ConditionRefresh Method AddressSpace definition

Attribute

Value

BrowseName

ConditionRefresh

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

AlwaysGeneratesEvent

ObjectType

RefreshStartEventType

Defined in 5.11.2

AlwaysGeneratesEvent

ObjectType

RefreshEndEventType

Defined in 5.11.3

ConformanceUnits

A & C Refresh