ConditionRefresh2 allows a Client to request a Refresh of all Condition instances that currently are in an interesting state (they have the Retain flag set) that are associated with the given Monitored item. In all other respects it functions as ConditionRefresh. A Client would typically invoke this Method when it initially connects to a Server and following any situations, such as communication disruptions where only a single MonitoredItem is to be resynchronized with the Server. This Method is only available on the ConditionType. 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 NodeId of the ConditionType ObjectType.

This Method is optional and as such Clients must be prepared to handle Servers which do not provide the Method. If the Method returns Bad_MethodInvalid, the Client shall 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 Subscription containing the MonitoredItem to be refreshed. The Server shall verify that the SubscriptionId provided is part of the Session that is invoking the Method.
MonitoredItemId	The identifier of the MonitoredItem to be refreshed. The MonitoredItemId shall be in the provided Subscription.

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

Table 24 – ConditionRefresh2 result codes

Result Code	Description
Bad_SubscriptionIdInvalid	See 10000-4 for the description of this result code
Bad_MonitoredItemIdInvalid	See 10000-4 for the description of this result code
Bad_RefreshInProgress	See Table 137 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 10000-4 for the general description of this result code.
Bad_MethodInvalid	See 10000-4 for the 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 and MonitoredItem identifier indicating which MonitoredItem in the selected Client Subscription shall be refreshed. If the Subscription and MonitoredItem is accepted the Server will react as follows:

1. The Server issues a RefreshStartEvent (defined in 5.11.2) marking the start of Refresh. The RefreshStartEvent is queued into the Event stream for the Notifier MonitoredItem in the Subscription.
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 a RefreshEndEvent (defined in 5.11.3) to signal the end of the Refresh. The RefreshEndEvent is queued into the Event stream for the Notifier MonitoredItem in the Subscription.

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

As mentioned above, ConditionRefresh2 shall also issue Event Notifications for 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 25 specifies the AddressSpace representation 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