Errata exists for this version of the document.

ConditionRefresh allows a Client to request a Refresh of all Condition instances that currently are in an interesting state (they have the Retain flag set). This includes previous states of a Condition instance for which the Server maintains Branches. A Client would typically invoke this Method when it initially connects to a Server and following any situations, such as communication disruptions, in which it would require resynchronization with the Server. This Method is only available on the ConditionType or its subtypes. To invoke this Method, the call shall pass the well-known MethodId of the Method on the ConditionType and the ObjectId shall be the well-known ObjectId of the ConditionType Object.

Signature

ConditionRefresh(

[in] IntegerId SubscriptionId

);

The parameters are defined in Table 18

Table 18 – ConditionRefresh parameters

Argument	Description
SubscriptionId	A valid Subscription Id of the Subscription to be refreshed. The Server shall verify that the SubscriptionId provided is part of the Session that is invoking the Method.

Method result codes in Table 19 (defined in Call Serv ice)

Table 19 – ConditionRefresh result codes

Result Code	Description
Bad_SubscriptionIdInvalid	See OPC 10000-4 for the description of this result code
Bad_RefreshInProgress	See Table 103 for the description of this result code
Bad_UserAccessDenied	The Method was not called in the context of the Session that owns the Subscription See OPC 10000-4 for the general description of this result code.

Comments

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

The input argument provides a Subscription identifier indicating which Client Subscription shall be refreshed. If the Subscription is accepted the Server will react as follows:

1. The Server issues an event of RefreshStartEvent Type(defined in 5.11.2) marking the start of Refresh. A copy of the instance of RefreshStartEventType is queued into the Event stream for every Notifier MonitoredItem in the Subscription. Each of the Event copies shall contain the same EventId.
2. The Server issues Event Notifications of any Retained Conditions and Retained Branches of Conditions that meet the Subscriptions content filter criteria. Note that the EventId for such a refreshed Notification shall be identical to the one for the original Notification, the values of the other Properties are Server specific, in that some Servers may be able to replay the exact Events with all Properties/Variables maintaining the same values as originally sent, but other Servers might only be able to regenerate the Event. The regenerated Event might contain some updated Property/Variable values. For example, if the Alarm limits associated with a Variable were changed after the generation of the Event without generating a change in the Alarm state, the new limit might be reported. In another example, if the HighLimit was 100 and the Variable is 120. If the limit were changed to 90 no new Event would be generated since no change to the StateMachine, but the limit on a Refresh would indicate 90, when the original Event had indicated 100.
3. The Server may intersperse new Event Notifications that have not been previously issued to the Notifier along with those being sent as part of the Refresh request. Clients shall check for multiple Event Notifications for a ConditionBranch to avoid overwriting a new state delivered together with an older state from the Refresh process.
4. The Server issues an instance of RefreshEndEventType (defined in 5.11.3) to signal the end of the Refresh. A copy of the instance of RefreshEndEventType is queued into the Event stream for every Notifier MonitoredItem in the Subscription. Each of the Events copies shall contain the same EventId.

It is important to note that if multiple Event Notifiers are in a Subscription all Event Notifiers are processed. If a Client does not want all MonitoredItems refreshed, then the Client should place each MonitoredItem in a separate Subscription or call ConditionRefresh2 if the Server supports it.

If more than one Subscription is to be refreshed, then the standard call Service array processing can be used.

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

Table 20 specifies the AddressSpace representation for the ConditionRefresh Method.

Table 20 – 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