First discussion telco May 8, 2012:

Two possible solutions:
(1) Add second Refresh method that operates on a monitored item
(2) Add a property to the ConditionType that indicates if the event was from a refresh

Agreed in telco that this will not be addressed in v1.02

Agreed to document the possibility of clients getting duplicate, unsolicited duplicate event notification. Document the "workaround" for clients is to use individual (multiple) subscriptions to prevent this.

Agreed to include in 1.03

We should add a Method ConditionRefresh2(SubscriptionId, MonitoredItemId) to 1.03. This is the only good long term solution. Since the method is only defined on the ConditionType, this would not affect instances.

An Alarm client can check for availability of this method and can call the old ConditionRefresh if the new one is not available.

Aded text to explain expected behaviour is multiple monitored item are in the subscription.

Did not add ConditionRefresh2. First we need to discuss how this will be compliance tested. It will be a 1.03 functionality and the CTT will need to be able to determine this and test accordingly.

Added ConditionRefresh2 method that include the Monitored item

UA meeting April 07:
Adding Refresh2 as optional CU to BaseCondition seems fairly useless.
Creating a version 2 of BaseCondition where Refresh2 is required causes a lot of effort (also for the CTT).

We finally decided to create a new facet that requires Refresh2.

fixed in OPC UA Part 7 - Profiles 1.03 Draft 08.docx.

Agreed to changes reviewed in telecon.