The following examples show the Eventflow for typical Alarmsituations. The tables list the value of state Variablesfor each Event Notification.
This example is for Serversthat do not support previous states and therefore do not create and maintain Branchesof a single Condition.
Figure B.1shows an Alarmas it becomes active and then inactive and also the acknowledgement and confirmation cycles. Table B.1lists the values of the state Variables. All Eventsare coming from the same Conditioninstance 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 |
Alarmgoes active. |
2 |
NULL |
True |
True |
False |
True |
Conditionacknowledged Confirm required |
3 |
NULL |
False |
True |
False |
True |
Alarmgoes inactive. |
4 |
NULL |
False |
True |
True |
False |
Conditionconfirmed |
5 |
NULL |
True |
False |
True |
True |
Alarmgoes active. |
6 |
NULL |
False |
False |
True |
True |
Alarmgoes inactive. |
7 |
NULL |
False |
True |
False |
True |
Conditionacknowledged, Confirm required. |
8 |
NULL |
False |
True |
True |
False |
Conditionconfirmed. |
*) The first row is included to illustrate the initial state of the Condition. This state will not be reported by an Event. |
This example is for Serversthat are able to maintain previous states of a Conditionand therefore create and maintain Branchesof a single Condition.
Figure B.2illustrates the use of branches by a Serverrequiring acknowledgement of all transitions into Activestate, not just the most recent transition. In this example no acknowledgement is required on a transition into an inactive state. Table B.2lists the values of the state Variables. All Eventsare coming from the same Conditioninstance and have therefore the same ConditionId.
Figure B.2– Previous state example
Table B.2– Example of a Conditionthat maintains previous states via branches
EventId |
BranchId |
Active |
Acked |
Confirmed |
Retain |
Description |
a) |
NULL |
False |
True |
True |
False |
Initial state of Condition. |
1 |
NULL |
True |
False |
True |
True |
Alarm goes active. |
2 |
NULL |
True |
True |
True |
True |
Condition acknowledged requires Confirm |
3 |
NULL |
False |
True |
False |
True |
Alarmgoes inactive. |
4 |
NULL |
False |
True |
True |
False |
Confirmed |
5 |
NULL |
True |
False |
True |
True |
Alarmgoes active. |
6 |
NULL |
False |
True |
True |
True |
Alarmgoes inactive. |
7 |
1 |
True |
False |
True |
True b) |
Prior state needs acknowledgment. Branch #1 created. |
8 |
NULL |
True |
False |
True |
True |
Alarmgoes active again. |
9 |
1 |
True |
True |
False |
True |
Prior state acknowledged, Confirm required. |
10 |
NULL |
False |
True |
True |
True b) |
Alarmgoes inactive again. |
11 |
2 |
True |
False |
True |
True |
Prior state needs acknowledgment. Branch #2 created. |
12 |
1 |
True |
True |
True |
False |
Prior state confirmed. Branch #1 deleted. |
13 |
2 |
True |
True |
True |
False |
Prior state acknowledged, Auto Confirmed by system Branch #2 deleted. |
14 |
NULL |
False |
True |
True |
False |
No longer of interest. |
a)The first rowis included to illustrate the initial state of the Condition. This state will not be reported by an Event. Notes on specific situations shown with this example: If the current state of the Conditionis acknowledged then the Ackedflag is set and the new state is reported (Event#2). If the Conditionstate changes before it can be acknowledged (Event#6) then a branch state is reported (Event#7). Timestamps for the Events #6 and #7 is identical. The branch state can be updated several times (Events #9) before it is cleared (Event#12). A single Conditioncan have many branch states active (Events #11) b)It is recommendedas in this table to leave Retain=True as long as there exist previous states (branches). |
This Clause provides additional examples for the use of HasNotifier, HasEventSourceand HasCondition Referencesto expose the organization of areas and sources with their associated Conditions. This hierarchy is additional to a hierarchy provided with Organizesand Aggregates References.
Figure B.3illustrates the use of the HasCondition Referencewith Conditioninstances.
Figure B.3– HasCondition used with Condition instances
In systems where Conditionsare not available as instances, the ConditionSourcecan reference the ConditionTypesinstead. This is illustrated with the example in Figure B.4.
Figure B.4– HasCondition reference to a Condition type
Figure B.5provides an example where the HasCondition Referenceis already defined in the Typesystem. The Referencecan point to a Condition Typeor to an instance. Both variants are shown in this example. A Referenceto a Condition Typein the Typesystem will result in a Referenceto the same Type Nodein the instance.
Figure B.5– HasCondition used with an instance declaration