This example is for Servers that are able to maintain previous states of a Condition and therefore create and maintain Branches of a single Condition.

Figure B.2 illustrates the use of branches by a Server requiring acknowledgement of all transitions into Active state, not just the most recent transition. In this example no acknowledgement is required on a transition into an inactive state. Table B.2 lists the values of the state Variables. All Events are coming from the same Condition instance and have therefore the same ConditionId.

image037.png

Figure B.2 – Previous state example

Table B.2 – Example of a Condition that 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

Alarm goes inactive.

4

NULL

False

True

True

False

Confirmed

5

NULL

True

False

True

True

Alarm goes active.

6

NULL

False

True

True

True

Alarm goes inactive.

7

1

True

False

True

True b)

Prior state needs acknowledgment. Branch #1 created.

8

NULL

True

False

True

True

Alarm goes active again.

9

1

True

True

False

True

Prior state acknowledged, Confirm required.

10

NULL

False

True

True

True b)

Alarm goes 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 row is 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 Condition is acknowledged then the Acked flag is set and the new state is reported (Event #2). If the Condition state 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 Condition can have many branch states active (Events #11)

b) It is recommended as 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.