ConditionRefresh2allows a Clientto request a Refreshof all Condition instances that currently are in an interesting state (they have the Retainflag set) that are associated with the given Monitored item. In all other respects it functions as ConditionRefresh. A Clientwould typically invoke this Methodwhen it initially connects to a Serverand following any situations, such as communication disruptions where only a single MonitoredItemis to be resynchronized 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.

This Methodis optional and as such Clientsmust be prepared to handle Serverswhich do not provide the Method. If the Methodreturns Bad_MethodInvalid, the Clientshall revert to ConditionRefresh.

Signature

ConditionRefresh2(

[in] IntegerId SubscriptionId

[in] IntegerId MonitoredItemId

);

The parameters are defined in Table 23

Table 23– ConditionRefresh2 parameters

Argument

Description

SubscriptionId

The identifier of the Subscriptioncontaining the MonitoredItemto be refreshed. The Servershall verify that the SubscriptionIdprovided is part of the Sessionthat is invoking the Method.

MonitoredItemId

The identifier of the MonitoredItemto be refreshed. The MonitoredItemId shall be in the provided Subscription.

Methodresult codes in Table 24(defined in Call Service)

Table 24– ConditionRefresh2 result codes

Result Code

Description

Bad_SubscriptionIdInvalid

See 10000-4for the description of this result code

Bad_MonitoredItemIdInvalid

See 10000-4for the description of this result code

Bad_RefreshInProgress

See Table 137for the description of this result code

Bad_UserAccessDenied

The Methodwas not called in the context of the Session that owns the Subscription

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

Bad_MethodInvalid

See 10000-4for the 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 and MonitoredItemidentifier indicating which MonitoredItemin the selected Client Subscriptionshall be refreshed. If the Subscriptionand MonitoredItemis accepted the Serverwill react as follows:

  1. The Serverissues a RefreshStartEvent(defined in 5.11.2) marking the start of Refresh. The RefreshStartEventis queued into the Eventstream for theNotifier MonitoredItem in the Subscription.
  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 notifier along 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 a RefreshEndEvent(defined in 5.11.3) to signal the end of the Refresh. The RefreshEndEventis queued into the Eventstream for theNotifier MonitoredItem in the Subscription.

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

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

Table 25specifies the AddressSpacerepresentation for the ConditionRefresh2 Method.

Table 25– ConditionRefresh2 Method AddressSpace definition

Attribute

Value

BrowseName

ConditionRefresh2

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 Refresh2