UA Part 9: Alarms and Conditions - B.1.3 Server maintains previous states

B.1.3 Server maintains previous states

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. c)
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). c) The system Auto confirms this event, since a confirmation is that the operator has taken some action. The confirmation of the previous state (line 12) indicates that the operator has taken an action and this transition does not require a separate confirmation.