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.
ConditionRefresh2( [in] IntegerId SubscriptionId [in] IntegerId MonitoredItemId );
The parameters are defined in Table 22
Table 22 – ConditionRefresh2 parameters
|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 23(defined in Call Service)
Table 23 – ConditionRefresh2 result codes
|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 135 for the description of this result code|
|Bad_UserAccessDenied||The Method was not called in the context of the Session that owns the SubscriptionSee 10000-4 for the general description of this result code.|
|Bad_MethodInvalid||See 10000-4 for the description of this result code|
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:
- 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.
- 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.
- 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.
- 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 24 specifies the AddressSpace representation for the ConditionRefresh2 Method.
Table 24 – ConditionRefresh2 Method AddressSpace definition
|AlwaysGeneratesEvent||ObjectType||RefreshStartEventType||Defined in 5.11.2|
|AlwaysGeneratesEvent||ObjectType||RefreshEndEventType||Defined in 5.11.3|
|A & C Refresh2|