This example is for Servers that do not support previous states and therefore do not create and maintain Branches of a single Condition.
Figure B.1 shows an Alarm as it becomes active and then inactive and also the acknowledgement and confirmation cycles. Table B.1 lists the values of the state Variables. All Events are coming from the same Condition instance and therefore have the same ConditionId.
Figure B.1 – Single state example
Table B.1 – Example of a Condition that only keeps the latest state
EventId |
BranchId |
Active |
Acked |
Confirmed |
Retain |
Description |
-*) |
NULL |
False |
True |
True |
False |
Initial state of Condition. |
1 |
NULL |
True |
False |
True |
True |
Alarm goes active. |
2 |
NULL |
True |
True |
False |
True |
Condition acknowledged Confirm required |
3 |
NULL |
False |
True |
False |
True |
Alarm goes inactive. |
4 |
NULL |
False |
True |
True |
False |
Condition confirmed |
5 |
NULL |
True |
False |
True |
True |
Alarm goes active. |
6 |
NULL |
False |
False |
True |
True |
Alarm goes inactive. |
7 |
NULL |
False |
True |
False |
True |
Condition acknowledged, Confirm required. |
8 |
NULL |
False |
True |
True |
False |
Condition confirmed. |
*) The first row is included to illustrate the initial state of the Condition. This state will not be reported by an Event. |