MODULE 2

Alarms and Events

An event is a record of conditions and activity within the system. The event history provides
a chronological record of changes in the system’s condition, as well as actions taken by
system users over time. An alarm is used to announce a significant event that requires an
operator’s immediate attention. The generation of an alarm also creates a corresponding
event record. However, the generation of an event does not necessarily create a
corresponding alarm.

You can configure conditions for the following:

• Generation of alarms
• Annunciation and display of alarms
• Suppression of alarms by conditions in other related points
• Printing of event logs

2.1 Events
The Event Summary window provides a detailed summary of the operational activity on
the SCADA system. Events are recorded both for operator-initiated actions and for
application-generated activities. A record is generated in the event summary when any of
the following occur:

• The system detects an alarmable condition

• A significant event occurs in an application
• The user issues commands to field devices
• The user modifies system configuration parameters
• The user acknowledges an alarm

2.1.1 Event Logging

When an event is generated, it is recorded in two locations. First, a copy is stored in the
HistoricalDB event table (refer to the Historical Reference). You can view the event
through the Event Summary window in XOS, as discussed in the Operation Reference).

Second, the event message is formatted and placed in the queue for the appropriate
spooler. The spooler process records the event on the appropriate log printer or in a log
file. The event message takes the form of a single line of text stating the nature of the
occurrence. For more information, refer to the Historical Reference. The group to which
the field device is assigned determines which spooler is used. The designated “system”
spooler is used for events that do not have an appropriate group. (Groups are discussed in
detail in the group Table (Module 8) in the RealTime Tables Reference).

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-2 RealTime Service Reference - Baseline

The event database will quickly fill with data if you do not empty or purge it periodically.
The archive/cleanup process performs the necessary database purging. If you store events in
a log file, you should periodically delete old entries from the log file. Spooling events to a
file is also discussed in the Historical Reference.

2.2 Alarms
The system generates two kinds of alarms: database alarms and system alarms. A database
alarm is always associated with a specific point in RealTimeDB. A condition that generates a
system alarm may or may not have a specific RealTime record associated with it. Most
alarms are database alarms.

Alarms refer to either a state or a significant event. If the alarm refers to a state, it persists
until the operator clears the condition that caused the alarm. For example, a value that
moved an analog point into a high alarm state would generate a state alarm, which persists
for the entire time that the point remains in that state. Even if the operator acknowledges
the alarm, the point remains in the Alarm Summary until the point’s value moves out of
that high alarm state.

If the alarm is caused by a transient condition or an event, the alarm is not persistent: it
vanishes from the Alarm Summary after the operator acknowledges it. For example, a rate-
of-change (ROC) alarm for an analog point is a non-persistent alarm. Such an alarm serves
to notify the operator of a condition that has occurred, even though the point may still be
well within its normal operational range.

InstAlarm automatically suppresses alarms that may occur when a point has recently been
commanded to change state, or when its alarm state has just changed. This component
helps reduce the number of nuisance alarms. For example, starting a pump could create a
pressure wave that causes several sensors downstream from the pump to go into an alarm
state temporarily. You can configure InstAlarm to suppress these alarms in the downstream
devices.

The alarm/event inhibit features available through XOS provide you with the flexibility to
specify whether or not a given point generates event messages or alarms.

The following baseline windows notify the operator of alarms:

• The Alarm Summary window

• The Newest Priority Alarms window
• The Station Alarm Summary window
• Alarm summaries for individual tables, such as analog, rate, and status

For more information on these windows, refer to the Operation Reference.

NOTE Within XOS, the system identifies an alarm condition by replacing the color of the
affected device or monitored value with a different solid or flashing color.

2.2.1 Instrument Fail Check

Sometimes, due to instrument or sensor malfunction, analog and rate instruments and/or
their associated transducers try to send a value to the RTU that is outside of the RTU’s
measurable range. If the Instrument Fail Check check box is selected for RTUs capable of
sensing instrument failures, an analog or rate point alarm is generated when an instrument
failure occurs.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
Module - Alarms and Events 2-3

For an RTU that is not capable of sensing “out-of-range” failures, selecting Instrument Fail
Check causes the generation of alarms whenever the RTU encounters a raw value that is
outside its measurable range.

If the RTU is not capable of sensing “out-of-range” failures, select Instrument Fail Check to
generate alarms whenever the raw value is not within the raw value range.

NOTE Instrument failure handling is protocol-specific. For more information, refer to

the Communication Management Reference.

2.2.2 Deadbands
The Alarm Deadband: field controls the sensitivity of the high and low alarms. These
alarms are always triggered when the value being monitored crosses the high or low limit.
The value that causes the alarm state to end depends on the deadband. When the point is
in the high alarm state, it remains in that state until it drops below the high limit minus
the deadband, as shown in the Deadband Example (Figure 2-1). These conditions prevent
minor fluctuations from repeatedly putting the value into and out of the alarm state.
Similarly, when a point is in the low alarm state, it remains in that state until it rises above
the low limit plus the deadband. If the deadband is set to zero, this feature is disabled.
These deadband rules apply in the same manner to the HiHi and LoLo limits.

Figure 2-1 Deadband Example

H H HH H L

High-High
Limit

High Limit
deadband

deadband
Low Limit

Low-Low
Limit

HH
= point in High-High alarm state

H
= point in Highalarm state

L
= point in Low alarm state

2.2.3 Alarm Limits

Standard normal operating values for the analog and rate points lie within certain Hi and
Lo limits. When a measured value exceeds the high limit, or goes below the low limit, a
state alarm is generated to indicate that a condition requires attention. A second set of
limits, known as HiHi and LoLo, are above and below the high and low limits. When a

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-4 RealTime Service Reference - Baseline

measured value exceeds the HiHi, or goes below LoLo limits, a state alarm is generated to
indicate that a critical condition has occurred.

Typically, a higher severity is assigned to HiHi / LoLo conditions than to the Hi/Lo. Refer to
State Message Sets (Section 4.1).

2.2.4 Rate-of-Change Checks

analog and rate instruments register a value that increases or decreases depending on
process conditions. InstAlarm can monitor the rate-of-change (ROC) in the value. Rate-of-
change is determined by normalizing the last scan value and the current value to the unit
time (in seconds):

lastvalue – currentvalue
ROC = --------------------------------------------------------------------
∆time

Some instruments have a manufacturer’s specification indicating that errors can occur if a
certain ROC value is exceeded. At times, a monitored process variable can require a ROC
limit to prevent errors based on rapid adjustments to the system. In these cases, select the
Rate of Change Alarm check box on the The Alarming tab in the analog Row Details dialog
box (Figure 2-8) in the RealTime Tables Reference, and enter the maximum allowable rate-
of-change (in engineering units per second) in the Rate of Change Limit: field. An alarm is
generated if the calculated rate of change is greater than this amount.

The correct limit is determined by the instrument specifications and the process limitations.

2.2.5 Creep Detection

You may need to properly calibrate analog and rate instruments to ensure that their values
are accurate and do not creep out of the calibrated state. analog and rate points have an
option that allows you to store an initial value or creep setpoint, updated on startup and
whenever a creep alarm is generated. This initial value can then be compared to all
subsequent values. This comparison measures any creep deviation of the input value. The
amount of creep is the absolute difference between the current scan value and the creep
setpoint that was set when the last creep alarm occurred:
creep = currentvalue – setpoint

If the analog point is supposed to test for creeping, select the Creep Detection check box on
the The Alarming tab in the analog Row Details dialog box (Figure 2-8) in the RealTime
Tables Reference. You should do this when the instrument specifications indicate a
maximum raw deviation value that is acceptable before calibration deterioration occurs.
Convert this raw value to the applicable engineering units for the point and enter it in the
Deviation Alarm Limit: field. An alarm is generated if the calculated creep exceeds this limit.

2.2.6 State-Based Alarming

State-based alarming is implemented for analog, rate, and status points. Both analog and
status points implement Intelligent Alarm Suppression. State-based alarming helps prevent
nuisance alarms, which occur when the actions of devices affect the readings of other
devices. High/low/creep/rate-of-change alarm checking is implemented for tables that hold
floating point values, such as analog and rate points.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
Module - Alarms and Events 2-5

status points can be configured to have normal and abnormal states. analog points have
lowlow/low/high/highhigh abnormal states and a normal state.

2.2.6.1 Abnormal State Alarming

Unless alarming of the state for a given status point is inhibited and the point shifts to an
abnormal state, the following occur:

• The point goes into alarm

• The appropriate workstation displays an alarm message
• The alarm message is spooled to the event log

If the alarm represents an abnormal state, it remains in the alarm summary as a non-
flashing alarm after it is acknowledged; it is then cleared from the Newest Priority Alarms
window. The name of the point, its associated remote, and its description field appear in
both the alarm message and the event log.

2.2.6.2 Return-to-Normal Alarming

When an alarm condition clears, the system:

• Generates a return-to-normal alarm message

• Clears the alarm from the alarm summaries after the operator ackowledges it
• Spools the return-to-normal alarm message to the event summary

When the alarm message is generated, it flashes until the user acknowledges it. After the
user acknowledges it, it stops flashing and is deleted from the alarm summary unless the
status point has been configured to sustain off-normal alarms. When the point returns to
normal, the return-to-normal alarm message appears on the user’s workstation and the
message begins flashing again. When the user acknowledges the alarm, the return-to-
normal alarm disappears from the alarm summary.

If the point returns to normal before the user acknowledges the alarm, the return-to-
normal alarm message is submitted to the user and remains flashing until it is
acknowledged. Even if the alarm condition clears before the alarm is acknowledged, the
user must still acknowledge the alarm.

NOTE An alarm is not generated if the user commands a status point to an abnormal
state.

2.2.7 Commanded status Points Alarming

Two types of alarm processing are associated with commanded status points:
uncommanded Change-Of-State (COS) and command failure.

NOTE State-based alarming is triggered whenever an uncommanded status change

occurs. A status point with a configured output can generate a state-based alarm if it
changes state without being commanded.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-6 RealTime Service Reference - Baseline

2.2.7.1 Uncommanded Change-of-State

An uncommanded change of state occurs when a status point changes state without being
commanded. The alarm message and event log will display the name of the status point, its
associated remote, and its description field.

When the user acknowledges an uncommanded change-of-state alarm, the alarm normally
disappears immediately from the alarm summary. However, if the status point has been
configured to sustain off-normal alarms, the system consults the abnormal state table. If the
state changed to an abnormal state, the alarm remains in the alarm summary even if the
user has acknowledged it.

Like state-based alarming, it is possible to independently disable alarming of transitions to

normal or abnormal states, as well as the logging of an uncommanded change-of-state.

NOTE An alarm is not generated if the user commands a status point to an abnormal
state.

2.2.7.2 Command Failure Alarming

There are two alarms associated with command failures: change-of-state failure alarm and
command failure timeout alarm.

The system generates a change-of-state alarm is generated when a device, which has been
directed or commanded to change state, takes a long time to change from its present state.
Some devices, such as large block valves, can take several minutes to attain the commanded
state. Rather than waiting for several minutes to generate a command failure alarm, you
can specify a maximum amount of time to wait for the device to change state. The state
which the device failed to reach is likely not the final state, but the fact that a change has
occurred indicates that the commanded action is taking place.

NOTE A change-of-state alarm applies only to status points configured as outputs.

The system generates the command failure timeout when the commanded device does not
reach the final commanded state within the maximum time allowed. Refer to Command
Failure Timeout Alarming (Section 2.2.8.1).

The only limitation on the time specifications is that the command failure timeout for the
final commanded state must be larger than the change-of-state failure timeout.

2.2.8 Timeout Alarms

User commands that are sent to analog and status points require a timeout period in which
to allow the device to perform the operation. If the operation is not performed within this
time, InstAlarm generates a timeout alarm.

NOTE rate points are typically flow measuring devices with no control capabilities;
therefore, rate records do not have this facility.

2.2.8.1 Command Failure Timeout Alarming

For status points, the timeout period for command failure (in seconds) is configured
through the Cmd Failure Timeout: field on the The Output tab for status Row Details dialog

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
Module - Alarms and Events 2-7

box (Figure 18-5), as described in the RealTime Tables Reference. This is the maximum
period of time for a command to succeed, after which the system issues a failure alarm.
The state that the device changes to is likely not the final state, but the fact that a change
has occurred indicates that the commanded action is taking place. A typical value would
be three to five seconds, but this is device dependent. If the device does not change state
within the specified period, the system generates an alarm.

If a command can not be sent to the status point due to communication problems, the
system generates an alarm and logs the event.

2.2.8.2 Command Timeout Alarming

For analog points, the timeout period for setpoint commands, in seconds, is configured
through the Command Timeout: field on the The Output tab in the analog Row Details
dialog box (Figure 2-7). Because analog values do not immediately stop at the setpoint,
there is also a Setpoint Tolerance value. A setpoint is reached when the value is within the
tolerance boundary (the setpoint value plus or minus the Setpoint Tolerance value). The
operation of the instrument plays an important role in determining the correct timeout
period. Generally, the correct timeout period will be arrived at by trial and error in the
testing of a commanded output. For more information on the The Output tab in the
analog Row Details dialog box (Figure 2-7), refer to the RealTime Tables Reference.

If a command can not be sent to the analog point due to communication problems, an
alarm is generated and the event is logged. All generated alarms are cleared from the
alarm summary upon acknowledgement.

2.2.9 Communication Alarms

The communication line between the RTU and the host computer may encounter minor
errors and problems. The statistics for communication errors are recorded in the remote
table, and then transferred to the HistoricalDB’s CommStats database, where they are
stored in the RemPeriodStats table. The connection statistics are recorded in the
connection table, and then transferred to the HistoricalDB’s CommStats database, where
they are stored in the ConnPeriodStats table.

To view historical results, click any field of a point’s information line on the Remote
Summary, Remote Primary Statistics Summary, or Remote Alternate Statistics Summary
window. (For more information on these summary windows, refer to the Operation
Reference.) When the action menu appears, click Historical Statistics to open the
Communications Statistics Edit dialog box, which displays historical results.

2.2.10 Communication Timeouts

The system reports most types of communication failures as soon as they occur (e.g.
security error, illegal message, short message). However, if the remote fails to
communicate, the system generates a no-reply alarm if the failure lasts for longer than the
no-reply timeout period.

2.2.10.1 Network Alarms

InstAlarm and InstEvent can also generate alarms related to critical network components
and the network communication between the host computers and the terminal servers.
For example, if the primary LAN fails over to the secondary LAN, an alarm message is
generated to indicate that a failover has occurred.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-8 RealTime Service Reference - Baseline

The following tables shows the messages for the internal network failover flag alarms
defined in the cpu message set.

Table 2-1 Network communication alarm text

Alarm Text Description

Fail The workstation CPU is failing over to backup unit (or there is a failing
LAN).
Pending The workstation CPU is attempting to start up.
Init The workstation CPU is in the initialization stage of recovery.
Standby Workstation CPU is in standby mode ready to go live if all conditions are
right.
Hot Workstation CPU is “hot” or live operational state.
Switch The host CPU and its LAN is failing, requiring a LAN switch. (This is also
used for device failover to another unit.)
Doswitch This is the process of switching LANs during a host CPU failover. (This is
also used for device failover to another unit.)

2.2.11 Non-Covered Alarms

There are situations when an alarm is generated from an area that is currently not selected
for control by any user. (This may happen on a night shift, for example, when fewer users
are on duty.) Any or all of the workstations can be configured to receive such non-covered
alarms.

When alarms are being generated for an area that is controlled by an operator, non-
covered alarms from another area occur only if alarm cover checking is enabled. If alarm
cover checking is disabled, the system will not generate non-covered alarms. For related
information, see The Main tab in the area Row Details dialog box (Figure 4-3) in the
RealTime Tables Reference

NOTE If a user receives a non-covered alarm, she does not automatically have the
authority to acknowledge it or to control the necessary devices in that area. First, she
must be able to select the area with the non-covered alarm for control, which can only
occur if the workstation rights and/or user rights allow it. At any given time, therefore, at
least one user should have rights to control each area. (Area of responsibility is discussed
in the RealTime Tables Reference.)

2.2.12 Logging Commanded COS and Setpoints

User-commanded status Change-Of-State (COS) and analog setpoints are both logged as
events. Successful commands are only logged with a success statement if Log Command
Success is selected in either the Analog Output dialog box or The Output tab for status Row
Details dialog box (Figure 18-5) (refer to the RealTime Tables Reference).

The system will record any permitted command issued by the operator (i.e. if the command
is aborted due to a command tag, the system will not record the event). Unsuccessful
commands are logged with the command and either a communication failure statement, if
communication failure prevented the command from reaching the remote, or a command
failure statement, as explained in Command Failure Timeout Alarming (Section 2.2.8.1) and
Communication Timeouts (Section 2.2.10).

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
Module - Alarms and Events 2-9

Most protocols process an output command at the RTU when the RTU is successful in
receiving the command.

2.3 Alarm Suppression

ADE manages alarms through the following:

• Parent Control Alarm Suppression (Section 2.3.1)

• Parent Alarm Suppression (Section 2.3.2)
• Transient Alarm Suppression (Section 2.3.3)
• almdisturbance Table (Module 1)

NOTE Alarm suppression applies to current value alarms (such as data krunching
alarms) and does not block other types of alarms (such as command failure alarms).

2.3.1 Parent Control Alarm Suppression

Parent control alarm suppression handles alarms by inhibiting alarm events that are a
direct and predictable result of an operator’s command to a field device. Starting a pump,
for instance, results in a pressure wave in the pipe. A pressure sensor further down the
pipeline from the pump would likely go into alarm when the pressure wave hits. By
configuring the sensor as a child of the pump device, it is possible to inhibit the alarm.

Relationships between parent and child points are configured in the RealTimeDB’s
almsuppression table. The almsuppression Table (Figure 16-1) offer a visual look at the
relationship. Extensions that are added to alarm suppression, such as alarm suppression
based on state, are also available for parent control alarm suppression. For more
information, refer to Parent Alarm Suppression (Section 2.3.2).

When an operator issues a control, for example setpoint, command to a field device, and
the command arrives successfully, the almsuppression records that have the controlled
point as parent are marked as suppressed. The alarm suppression timeout is set up, and at
expiration, the children’s alarm conditions are reevaluated. If at reevaluation the child is in
a different alarm state from where it was when the parent was commanded, the system
generates an alarm. The parent control alarm suppression is then cleared. If the control
command failed to execute at the remote, then the alarm suppression timeout is cancelled
and any suppressed child alarm is immediately evaluated.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-10 RealTime Service Reference - Baseline

Figure 2-2 Parent Control Alarm Suppression Example

Child State
hi hi alarm

hi alarm
control suppression timeout
normal

0 10 20 50 100 120 Time (seconds)

Parent is commanded
New value arrives Child state is reevaluated. It
at time 0 and child is
indicating that the child is found to be the same as at
marked for alarm
is in alarm, but the alarm time 0; therefore, no alarm is
suppression.
is suppressed. generated.

In the Parent Control Alarm Suppression Example (Figure 2-2), the state of the child goes
into alarm shortly after the command is sent to the parent. The child returns to normal at
the 100-second mark. If the control suppression timeout is set to a value greater than 100
seconds, then the child will not alarm: it has returned to normal before the alarm
suppression timeout expired. If the timeout value were shorter, for instance 90 seconds,
then the child alarm is generated after 90 seconds.

NOTE If a parent is commanded while a control suppression timeout is already under

way, then the control suppression timeout will be reset. However, when the updated
alarm suppression timeout value expires, control suppression does not record a new
child state value for evaluation.

NOTE Only child state alarms that result from data krunching are suppressed by parent
control alarm suppression. Other types of alarms (e.g. command failure) execute as nor-
mal. Parent control alarm suppression is supported for analog and status points.

2.3.2 Parent Alarm Suppression

With parent alarm suppression, child alarms are suppressed on the basis of the parent’s
alarm state.

When a parent with alarm suppression records goes into alarm, the children’s alarms are
suppressed for a configured amount of time (i.e. a timeout value). Child alarm suppression
is cancelled after the timeout value has expired. When the timeout value expires, the
system reevaluates the alarm state of the children.

NOTE Timeout values are not reset if the parent toggles between alarm states.

In the case of alarm suppression based on the child alarm state, child alarm suppression is
cancelled when a non-suppressed state is reached. In this event, the parent alarm timers for

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
Module - Alarms and Events 2-11

alarm, return-to-normal, and alarm hold-off are either cancelled or prevented from being
triggered. For example, assume that a child is configured for parent alarm suppression in
the normal, hi, and low alarm states. If the point’s parent changes alarm state, the parent’s
alarm remains suppressed while it remains in the normal, hi, or low alarm state. If the
parent reaches the high-high or low-low alarm state, its alarm suppression is cancelled
immediately and the system generates an alarm.

Parent alarm suppression only suppresses child state alarms that result from data
krunching. Other types of alarms (e.g. command failure) execute as normal. Parent alarm
suppression is supported for analog and status points.

2.3.2.1 Parent Alarm Timeout

When a parent point goes into alarm or enters a different alarm state, the children (i.e.
the almsuppression records that have the alarmed point as their parent) are marked as
suppressed. The alarm suppression timeout is set up, and, at expiration, the children’s
alarm conditions are reevaluated. If at the time of reevaluation the child is in a different
alarm state than where it was when suppression was triggered, the system generates an
alarm. The alarm suppression is cleared once the alarm suppression timeout expires.

If configured for state-specific suppression, the child alarms that come into the system are
checked to ensure that they match the configured state(s) to be suppressed.

Figure 2-3 Parent Alarm Suppression Example

Parent
Alarm State

alarm
Child2
Child1
Child2 alarm suppression timeout

normal Child1 alarm suppression timeout

10 60 100 115 130 Time (Seconds)

rent goes into alarm Child1 returns to

d children are marked Child alarms normal without Child2 is in a different state from
r alarm suppression are suppressed generating alarms where it was at the time of alarm
Parent returns suppression; therefore, an alarm is
to normal generated for Child2.

In the Parent Alarm Suppression Example (Figure 2-3), the parent alarm occurs and the
children alarms are suppressed. The parent returns to normal before the alarm suppression
timeout value expires.

Children alarms are reevaluated when the parent alarm timeout value expires. This value
can be set to a relatively short value or to a value that is beyond the parent’s alarm
duration.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-12 RealTime Service Reference - Baseline

NOTE The alarm suppression timeout value is not reset if the parent transitions to nor-
mal and then back to alarm state before the timeout value expires.

2.3.2.2 Parent Return-to-Normal Timeout

The parent Return-to-Normal (RTN) timeout value assists in suppressing child alarms that
are held until after the parent returns to normal. This timeout value can be used either with
or without a configured parent alarm timeout value.

In the Parent Alarm Suppression Example (Figure 2-3), if Child2 stays in alarm for a period of
time after the parent returns to normal, then the parent RTN timeout is used rather than
the parent alarm timeout. In this case, the parent alarm timeout is set to zero, which causes
the indefinite suppression of the children alarms while the parent is in the alarm state. This
timeout value is set so that child alarm reevaluation is made after the parent has been in
the normal state for the timeout duration (e.g. 80 seconds).

Figure 2-4 Parent Return-to-Normal Suppression Example

Parent
Alarm State

alarm
Child2
Child1
Child2 alarm suppression timeout

normal Child1 alarm suppression timeout

10 60 100 115 130 Time (Seconds)

Parent goes into alarm Child1 returns to

and children are marked Child alarms normal without Child2 is in a different state from
for alarm suppression are suppressed generating alarms where it was at the time of alarm
Parent returns suppression; therefore, an alarm is
to normal generated for Child2.

The parent RTN alarm suppression timeout can be used in combination with the parent
alarm suppression timeout. The Parent Return-to-Normal Suppression Example (Figure 2-4)
shows both timeout values configured. In this case, the parent returns to the normal state
and the RTN alarm suppression timeout extends the suppression interval. As the child
returns to the same state it was in at the time of suppression, the system will not generate
any child alarms. If the parent stays in the alarm state for more than 40 seconds, the RTN
timer is not triggered; the system reevaluates the child and, consequently, generates an
alarm.

NOTE If only the RTN suppression is configured (i.e. alarms are indefinitely suppressed
while the parent is in alarm), then the suppression is cleared if the remote containing the
parent goes stale due to communication failure or the remote being placed offscan.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
Module - Alarms and Events 2-13

NOTE Regardless of the configuration of the timeout values, the child’s state is com-
pared to its state when the parent went into alarm after all timers have expired. The
child’s alarm state is not reevaluated as each timeout value (or timer) expires.

The timeout values are not reset during transitions between alarm states or during
transitions between normal states. The alarm suppression timeout value is cleared when
the parent shifts into a normal state and after the successful setup of the RTN alarm
suppression timeout. However, if the parent shifts back into an alarm state while the RTN
timer is active, then the system will neither clear the RTN alarm suppression timeout value,
nor set up an alarm suppression timeout value. This avoids the indefinite suppression of
alarms when the parent toggles continuously between abnormal and normal states.

2.3.3 Transient Alarm Suppression

Transient alarm suppression is invoked when a status point changes state or an analog
point changes between the high/low alarm states. In this case, the child does not have a
parent. When triggered, the alarm hold-off timer records the child’s current state and
marks the child as alarm-suppressed. When the alarm hold-off timer expires, the system
determines if it should generate an alarm by comparing the current state of the child to
the recorded state at the time the hold-off timer is triggered.

Figure 2-5 Transient Alarm Suppression Example

alarm
Alarm State

Child

Hold-off Timeout

normal
Time (Seconds)

Child goes into Child returns to normal before

alarm and hold-off hold-off timeout expires; therefore,
timer is triggered. no alarm is generated.

The alarm hold-off timer is not triggered anew if a new telemetry value is received for the
child while the alarm hold-timer is in effect.

2.3.4 Alarm Hold-off

Alarm hold-off is used to temporarily suppress child state alarms that result from data
krunching. Other types of alarms, such as command failure, execute as normal. Alarm
hold-off is supported for analog and status points.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-14 RealTime Service Reference - Baseline

2.3.4.1 Communication Order and Alarm Suppression

Communication order can cause real-time events to be reported in an order that differs
from the actual order in which they occurred. This can result in false alarms that would
normally be suppressed using Alarm Suppression. The alarm hold-off timer helps delay
alarm processing to counter the effects of communication order. The Alarm Hold-off
Example (Figure 2-6) illustrates the concept.

Figure 2-6 Alarm Hold-off Example

Telemetered Child

Telemetered
Real Parent Parent
alarm Alarm Suppression Timeout
Alarm State

Hold-off
Timeout

normal
Time (Seconds)

Real Parent
goes into alarm. Child goes into the Parent suppresses Child returns to
alarm state but child alarm and normal without
alarming is delayed Alarm Hold-off generating alarms.
by the Alarm Hold- timer is cancelled.
off timer.

If there is no method to delay the evaluation of the child’s alarm state until the parent
alarm state is updated, then suppression occurs after the child has gone into alarm. Both
alarm and RTN alarm events are generated for the child. The alarm hold-off timer
postpones the alarm long enough to receive the updated parent value.

In the Alarm Hold-off Example (Figure 2-6), alarm hold-off is triggered when the child
enters the alarm state. The alarm hold-off saves the child’s previous value for comparison
with the value when the timer expires. The parent goes into alarm, sets the alarm
suppression timeout, and cancels the alarm hold-off timer. However, the parent does not
change the child value that is saved by the alarm hold-off. When the alarm suppression
timeout expires, the child is back to its original state; therefore, no alarm is generated.

NOTE The alarm hold-off timer is triggered when the point’s alarm state changes and
neither its parent alarm nor return-to-normal alarm has suppressed it. The alarm hold-off
timer is cancelled if its parent goes into an alarm state before the hold-off timeout
expires.

2.4 Interaction Between Suppression Types

The combination of alarm suppression types does not affect the performance of each type.
An alarm is suppressed when it satisfies one of the suppression criteria.

The following illustrates the interaction of the different suppression types:

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
Module - Alarms and Events 2-15

• When the alarm hold-off timer prevents a point from being alarmed, then alarms
are suppressed for any child records of the point that are specified for parent
alarming or transient alarm suppression.
• When the child of a point that is specified for parent alarming goes into alarm,
and its alarm is suppressed, the child suppresses alarming of any of its children that
are configured for parent alarm suppression.
• When a point’s alarm is reevaluated at expiration of a suppression timer (e.g. par-
ent alarm timer), the system evaluates any suppression criteria before generating
an alarm.

2.4.1 Alarm Suppression Overview

The Alarm Suppression Overview window (Figure 2-7) provides a visual view of the
different alarm suppression types and the points with which a selected point is involved.

Opening the Alarm Suppression Overview window

• Click Suppression Overview on the DMT.

Figure 2-7 Alarm Suppression Overview window

The window shows a selected point with a parent point that triggers parent control alarm
suppression for the point. It also shows a child point for which this point triggers parent
alarm suppression. Any transient alarm suppression configured for the point is also
displayed. If the selected point had multiple parent alarm-suppression triggers, or multiple
children for which it triggered alarm suppression, then they would also be displayed.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-16 RealTime Service Reference - Baseline

Selecting a point to view on the Alarm Suppression Overview window

Refer to the Alarm Suppression Overview window (Figure 2-7) to complete these steps.

1 Click the Table drop down arrow and select the table to which the point belongs.
2 In the Point: field, type or select the name of the point.
The selected point’s parents and children are displayed.

NOTE Clicking the parent and child Edit buttons reveals details about the alarm sup-
pression relationship between the selected point and its parent and child. You can also
modify the relationship using the Edit button.

2.4.2 Alarm Suppression Behavior

The suppression behaviors are additive. For example, if a child point is configured for
parent control, parent alarm, and transient alarm suppression, then timers for all the
configured suppression types may be active at any time. However, to determine if an alarm
should be generated, the system compares the alarm state when the first suppression is
triggered to the state when the last suppression timeout ends.

If, for instance, (a) a control suppression event is followed by a parent alarm suppression
event, and (b) the child point’s state changes, then after the control suppression timeout
expires, the system does not generate an alarm because the child is still suppressed by
parent alarm suppression. In the event that the parent alarm suppression timeout expires,
and no suppression timeout exists for the child, then the child point’s current state is
compared to the state when the control suppression trigger occurred. If it is different, then
the system generates an alarm.

In addition, XOS summary and annotated displays show the alarm icon next to the child
data whenever the child is in the alarm state, regardless of alarm suppression. The
suppression only applies to the alarm summary displays.

The alarm event is also recorded within the event summary. If the child point’s alarm state
changes during the suppression timeout, the summary shows when the system triggers and
cancels alarm suppression.

The analog and status summaries can show filtered lists of points that are currently in alarm
suppression. The summaries show child points actively suppressed if they have undergone
an alarm state change since alarm suppression was triggered.

2.5 The almsum Table

When an alarm is generated, the system writes a record to the RealTimeDB almsum table.
Each record stores information about the alarm including the following:

• The name of the point, table, and group with which the alarm is associated
• The severity of the alarm
• The type of alarm
• The message text
• Whether or not the alarm is persistent (a persistent alarm remains in the alarm sum-
mary even after the user acknowledges it)

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
Module - Alarms and Events 2-17

The following table lists all of the fields in the almsum table.

Table 2-2 Fields in the RealTimeDB almsum table

Internal
Field Name Data Type Description
category pntname The alarm category (e.g. command-failure, rate-of-
change, or hi-state).
covered oas_boolean_t This indicates whether or not this alarm is currently in an
XOS control area.
dbname pntname The name of the table with which the alarmed point is
associated. For system alarms, this field is set to SYSTEM.
DBnPnt almsum_dbpnt The database key field.
flashing oas_boolean_t When the alarm is flashing, it is unacknowledged.
fldname fieldname The name of the field in alarm.
group groupslot The group with which this point is associated for alarm-
ing.
host pntname The host machine name.
inalarm oas_boolean_t This indicates whether or not the alarm is persistent.
message almsumMsg The alarm message text.
pntdesc pntdescription The point description.
ptname almsum_key The name of the point in alarm.
purgetimer short The purge timer, in seconds, is used when a non-persis-
tent alarm is to remain in the summary for a time after
alarm acknowledgement.
rtu remoteslot The remote point.
severity sev_enum The alarm severity.
Sevtime alm_sevtime_t The severity and timestamp combined, which is used as a
database key.
timestamp internaltime The time, in number of seconds, from 00:00:00 hours
(GMT), January 1, 1970, when the alarm occurred.
timestampstr alm_timestr_t The timestamp as a string in local time format.
type almTypeEnum The alarm type (e.g. database or system).

The almsum table is not accessible through the DMT. Use the following to access or modify
the table:

• acknowledge
• addDBalarm
• addSYSalarm
• filteralm

Each of these is described in the Business Object Reference.

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent
2-18 RealTime Service Reference - Baseline

OASyS® DNA SCADA Suite Baseline Document Revision 1.0

Proprietary and Confidential to Telvent