A & C Alarm

Support for Basic Alarm functionality, including active, inactive states. Note: RTN = Return to Normal


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

000

CTT Unavailable  Browse()  Browse the address-space type definitions starting at the ConditionType node. Verify the "AcknowledgeableConditionType" is nested and then follow its references. Verify the "AlarmConditionType" is nested and follow all of its references to identify all Alarm Condition types. Cache all NodeIds of interest. Each AlarmCondition complies to the specifications. The references exist as specified. Each reference complies to the specification as described in UA Part 9 Table 30 AlarmConditionType model.

Spec Link: Part 9->Table 30, Section 5.8.2

001

CTT Unavailable  Prepare a list of ALL fields (including inherited) that can be filtered (in a SELECT clause). Create a number of monitored items (server object in all cases, just updated filters). In a loop, add the ""next"" field to a SELECT clause in a MonitoredItem.Filter and then move to the next monitored item (i.e. each monoted item has a progressly large list of fields).

Note: A single WHERE clause to receive this type of Alarm only.
The fields list array (to be tested) should start with the EventId. Note: the loop should jump 3 or 4 at a time (not 1 at a time).
Step #
Action
Expected Result(s)

1

Server accepts the subscription/monitoring request.

2

Call publish and wait for an event.

The event is received in the Publish response and contains the list of fields requested only.

002

CTT Unavailable  check that an Alarm appear and returns to normal
Step #
Action
Expected Result(s)

1

Event received and alarm ActiveState is TRUE.

2

Call acknowledge and/or confirm on the alarm (that has returned to normal)

Event received, alarm ActiveState is FALSE, Retain bit is FALSE (and it is Acknowledge and/or Confirmed)

003

CTT Unavailable  check that multiple Alarm appear and returns to normal
Step #
Action
Expected Result(s)

1

Event received and alarm ActiveState is TRUE, for every alarm

2

Call acknowledge and/or confirm on multiple alarm (that have returned to normal)

Event received, alarm ActiveState is FALSE, Retain bit is FALSE (and it is Acknowledge and/or Confirmed) for every alarm

004

CTT Unavailable  If the InputNode property is not null, Select an alarm and read the value of the nodeid that was returned from the InputNode property The read returns a valid value (no errors)

005

CTT Unavailable  Call()  Invoke an event by writing to a trigger.
Call publish.
Step #
Action
Expected Result(s)

1

Event received and alarm ActiveState is TRUE. Spec Link: Part 9->Table 30, Section 5.8.2

2

Set Suppress trigger (if available) and call Publish. "This step is based on a trigger and may or may not be available. Test should be allowed to exit gracefully if unavailable. NOTE: Identify HOW to configure this within the CTT settings, which might also help identify how to structure this in the Standardized Address Space XLSX.

Event received and alarm ActiveState is TRUE, SuppressedOrShelved is TRUE.

3

Acknowledge the event and call Publish.

Event received, alarm ActiveState is TRUE, Retain bit is TRUE, SuppressedOrShelved is TRUE.

4

Unset Suppress trigger and call Publish.

Event received and alarm ActiveState is TRUE, Retain bit is TRUE, SuppressedOrShelved is FALSE.

5

Invoke the RTN trigger, call publish.

Event received, alarm ActiveState is FALSE, Retain bit is FALSE, SuppressedOrSlelved is FALSE.

006

CTT Unavailable  Call()  Invoke an event several times by writing a sequence of event trigger followed by RTN trigger.
Call publish.
Ensure adequate subscription queue size so that no notifications are discarded.
Step #
Action
Expected Result(s)

1

Events are received, alternating ActiveState TRUE/FALSE. Spec Link: Part 9->Table 30, Section 5.8.2, 5.5.3

2

Acknowledge the most current event (based on the timestamp) and call Publish. Note: If condition supports branching then multiple acknowledgements will be required, one for each BranchId

One or more events are received. Final event shows ActiveState is FALSE, Retain bit is FALSE.

007

CTT Unavailable  Call()  Invoke an event by writing to a trigger.
Call publish.
Step #
Action
Expected Result(s)

1

Event received and alarm ActiveState is TRUE. Spec Link: Part 9->Table 30, Section 5.8.2, 5.5.3

2

Invoke an event several times by writing a sequence of RTN trigger followed by event trigger. Call publish. Note: Ensure adequate subscription queue size so that no notifications are discarded.

Events are received, alternating ActiveState TRUE/FALSE.

3

Acknowledge all events. Note: If condition supports branching then multiple acknowledgements will be required, one for each BranchId.

One or more events are received. Final event shows ActiveState is TRUE, Retain bit is TRUE. One successful acknowlegment, and all others will be BadEventIdUnknown.

4

Invoke the RTN trigger, call publish.

Event received, alarm ActiveState is FALSE, Retain bit is FALSE.

008

CTT Unavailable  Call()  Invoke an event by writing to a trigger.
Call publish.
Augment filter so that RefreshStartEvent and RefreshEndEvent are also queued for delivery in publish response.
Step #
Action
Expected Result(s)

1

Event received and alarm ActiveState is TRUE, Retain bit is TRUE. Spec Link: Part 9->Table 30, Section 5.8.2, 5.11

2

Invoke Refresh and call Publish.

Event received and alarm ActiveState is TRUE, Retain bit is TRUE.

3

Invoke the RTN trigger, call publish.

Event received, alarm ActiveState is FALSE, Retain bit is TRUE.

4

Invoke Refresh and call Publish.

Event received, alarm ActiveState is FALSE, Retain bit is TRUE.

5

Acknowledge the event and call Publish.

Event received, alarm ActiveState is FALSE, Retain bit is FALSE.

6

Invoke Refresh and call Publish.

No Event is received.

009

Lab Using whatever means are available, suppress an Alarm.Try to invoke the suppressed alarm using whatever means are available. Ideally, the Server should provide a trigger to provide this capability. The alarm is never raised, so no event(s) are received about it.