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.

image036.png

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.

image037.png

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.

This example adds additional fields to the model illustrated in B.1.2. This example does not use acknowledge or confirm – it assumes that the alarm is automatically acknowledged (and does not support confirm). It does add OutOfServiceStateand SuppressedState.

Figure B.3 shows an Alarmas it becomes active, is suppressed or is placed out of service and then inactive. Table B.3 lists the values of the state Variables. All Eventsare coming from the same Conditioninstance and therefore have the same ConditionId. The Clientsubscription includes an event filter that excludes suppressed or out of service conditions (i.e. SuppressedState= True or OutOfServiceState= True). The events shown in green are delivered to the Client. The Retain column indicates the global value of the Retainflag. The “Retain sent” column indicates the overridden value sent in a notification if SupportsFilteredRetainis True. If SupportsFilteredRetainis False the value from the Retain column is sent.

image038.png

Figure B.3– SuppressedState and OutOfServiceState example

Table B.3– Example of a Condition that is Suppressed / OutOfService

EventId

Active

Suppressed

State

OutOf

Service

State

Retain

Retain sent

Event Deliver with Filter

Description

-*)

False

False

False

False

False

-

Initial state of Condition.

1

True

False

False

True

True

Yes

Alarm goes active.

2

True

False

True

True

False

Yes

Placed OutOfService

3

True

True

True

True

False

No

Alarm Suppressed; No event since OutOfService

4

False

True

True

False

False

No

Alarm goes inactive; No event since OutOfService

5

False

False

True

False

False

No

Alarm not Suppressed; No event since not active

6

True

False

True

True

False

No

Alarm goes active; No event since OutOfService

7

True

False

False

True

True

Yes

Alarm no longer OutOfService; Event generated

8

False

False

False

False

False

Yes

Alarm goes inactive

9

False

True

False

False

False

No

Alarm Suppressed; No event since not active

10

True

True

False

True

False

No

Alarm goes active; No event since Suppressed

11

False

True

False

False

False

No

Alarm goes inactive; No event since Suppressed

12

False

False

False

False

False

No

Alarm no longer Suppressed

13

False

False

True

False

False

No

Placed OutOfService

14

True

False

True

True

False

No

Alarm goes active; No event since OutOfService

15

False

False

True

False

False

No

Alarm goes inactive; No event since OutOfService

16

False

False

False

False

False

No

Alarm no longer OutOfService

This behaviour occurs when the implementation supports SupportsFilteredRetain flag subscription.

This example illustrates how on-delay, off-delay and alarm dead bands can be used to reduce the number of alarms that are generated / reported (see 5.8). It also illustrates how ReAlarmTimeis used to bring an alarm back up to an active state (see Figure B.4).

Some process values may have sudden jumps that are very brief and do not constitute an alarm. For example, a motor on start draws a large current, but quickly come back down. This is a normal motor current load, and should not be alarmed, but a sustained current load is a problem and should be alarmed, by configuring a OnDelaytime, the momentary spike will not generate an alarm, since the value has to be above the alarm threshold for the duration of OnDelay.

An AlarmDeadbandis used to keep a noise signal from generating multiple Alarm activations a signal once it crosses an alarm limit will not return to norm unless it drops below the limit by the amount of the deadband specified. In the example the process value is jumping up and down around the limit, but the alarm just remains in the same active or acknowledged state. The Alarm can have a deadband for each limit (High vs HighHigh) and these deadbands can be different.

The OffDelaycan also be used, much as the OnDelay, except it will keep a Value in alarm even if it drops below a limit, but only very briefly. Again, this setting is used to limit the number of alarms that occur in a system.

The ReAlarmTimeis used to ensure that actions are taken to correct the issue that generated an alarm. Some alarms are configured to generate a new alarm if they have been in an active state for the ReAlarmTimeperiod. The Alarm, goes back to an Unacknowledged state, as if it had just occurred.

image039.png

Figure B.4- Alarm example - On Delay, Off Delay, ReAlarmTime

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.5illustrates the use of the HasCondition Referencewith Conditioninstances.

image040.png

Figure B.5– 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.6.

image041.png

Figure B.6– HasCondition reference to a Condition type

Figure B.7provides 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.

image042.png

Figure B.7– HasCondition used with an instance declaration