A & C Refresh

Supports ConditionRefresh Method and the concept of a refresh.


Questions? Contact us
Generated: 21/11/2021 at 17:21:20 p.m.
A & C Refresh - 13 Test Cases
Test Case Id Test Type Keywords Test Case Description Test Requirements Expected Result

000

CTT Walk through the address space and verify the "ConditionRefresh" method exists on "ConditionType" type. The browse path should be Root\Types\ObjectTypes\BaseEventType\ConditionType\ConditionRefresh The ConditionType ObjectType node.
Step #
Action
Expected Result(s)

1

The method exists in the right places and its signature matches the specifications, i.e. "void ConditionRefresh( [in] integerId subscriptionId )". The BrowseName is "ConditionRefresh" and has 3 references: "HasProperty" and 2 instances of "AlwaysGeneratesEvent". Service and operation results: Good Spec Links: Part 9->5.5.7 and Table 18

2

Verify the ConditionRefresh() method does not exist for derived types.

The method only exists on the ConditionType definition object: ObjectId: i=2782 MethodId: i=3875

001

CTT Connect to the Server, create a subscription for an MonitoredItem (Notifier) and invoke ConditionRefresh().
The order of events should be:
- RefreshStartEventType
- List of Retained Conditions (as ConditionType or ConditionType subtypes)
- RefreshEndEventType

Service/operation results: Good;
SpecLink: Part 9->4.5; Part 9->5.5.7

002

CTT Connect to the Server, create a subscription for two MonitoredItem (Notifier) and invoke ConditionRefresh(). The order of events should be:
- RefreshStartEventType
- List of Retained Conditions (as ConditionType or ConditionType subtypes)
- RefreshEndEventType
for each monitored Item

Service/operation results: Good
SpecLink: Part 9->4.5; Part 9->5.5.7

003

CTT Create 2 subscriptions with each have a monitored item with a different (unique) filter. Invoke ConditionRefresh for each subscription.
Server must support 2 or more subscriptions. Both subscriptions return events that are specific to the subscription Filter. A RefreshStartEvent is received along with the events, and then a RefreshEndEvent.
ServiceResult = Good;
OperationResults = Good;

004

CTT Verify the structure of a RefreshStartEventType event.
This test will use a cached version of an event that should have been previously received. The event should match.
SpecLink: Part 9->5.11.2

005

CTT Verify the structure of a RefreshEndEventType event.
This test will use a cached version of an event that should have been previously received. The event should match.
SpecLink: Part 9->5.11.2

006

CTT Create two sessions with a valid configuration for events. Then call ConditionRefresh on one Subscription.
Server must support 2 or more sessions. Expect refresh events only on the session that called refresh.
ServideResult/OperationResults = Good

007

CTT Create a subscription for events and observing the communication for a while (e.g. until 10 Alarms have been received). After receiving several Alarms call the ConditionRefresh method and see if all Alarms are reported. All previous events can be received.
The order of events should be:
- RefreshStartEventType
- List of Retained Conditions (as ConditionType or ConditionType subtypes)
- RefreshEndEventType

ServiceResult/OperationResults = Good

008

CTT Create a subscription for events and observing the communication for a while (e.g. until 10 alarms have been received).
After receiving several events create a second session with the same configuration for a subscription and MonitoredItem and call the ConditionRefresh2 method and see if all alarms are reported.
All previous alarms can be received.
The order of events should be:
- RefreshStartEventType
- List of Retained Conditions (as ConditionType or ConditionType subtypes)
- RefreshEndEventType

ServiceResult/OperationResults = Good

Err-001

CTT Specify an invalid SubscriptionId. No Subscription shall exist in the session. Invocation fails.

Service Result = Good.
Operation result = BadSubscriptionIdInvalid

Spec links: Part 9->Table17

Err-003

CTT Call()  Create a valid Subscription to monitor Events. Invoke ConditionRefresh again and specify an invalid SubscriptionId. 2nd invocation fails.

Service result:Good
Operation result: BadSubscriptionIdInvalid

Spec links: Part 9->Table17

Err-004

CTT Add two or more refresh ConditionRefresh calls (near simultaneously).
One call should succeed whereas the other should fail.

If one does not fail it might require manual testing.

ServiceResult = Good;
OperationResults = BadRefreshInProgress;

Spec links: Part 9->Table17

Err-005

Create two sessions with a valid configuration for events. Then call ConditionRefresh in the first Session specifying the SubscriptionId from the second Session. Server must support 2 or more sessions. Server is declining the request
ServiceResult = Good
OperationResults = BadUserAccessDenied or BadSubscriptionIdInvalid