Integrated Alarm Environment

Chapter 43
43.1 Database
43.2 Display Systems
43.3 Alarm Lists
43.4 Integrated Safety Environment
43.5 Alarm Management Policy
43.6 Comments

Computer control makes an important contribu- Table 43.1 Analogue input function and data block
tion to safety. This is discussed in more detail in
Function block Datablock
Chapter 55. Of particular significance is the ca-
Slot Description Value
pacity for the systematic handling of alarms which
pervades system design. Thus, for example, alarm 1 Block no. B1005
features are built into the database for processing 2 Block type AIN
by both the DDC and OCP packages. This chap- 3 Tag no. LRC 47
ter summarises those features that are typical. It is
4 Description Buffer tank
also used as a vehicle to introduce various aspects level
of database design.
5 Block status On
For a more comprehensive treatment of the
6 Sampling frequency 5
subject the reader is referred to the guide on the de-
7 Frame/rack/card/channel no. 1/2/10/06
sign, management and procurement of alarm sys-
tems published by EEMUA (1999). 8 Characterisation LIN
9 Bias −0.1
10 Span 2.1
11 Engineering units m
43.1 Database 12 Display area 06
Function blocks are configurable and consist of 13 Alarm priority 0
a routine, i.e. a program or set of algorithms, 14 High alarm limit 1.8
which operate upon associated blocks of data in 15 Low alarm limit −0.1
the database. The function blocks exist within a 16 Deadband 0.05
DDC package and are under control of the RTOS. 17 Message code 0
Their associated blocks of data are invariably re- 18 Result
ferred to as data blocks. The use of function blocks
is elaborated upon in the following chapters and
their configuration is explained in Chapter 48. 47. The signal is processed by a function block of
Consider an analogue input signal. This may, the type AIN whose purpose is to scale analogue
for example, relate to some level control loop LRC input signals. The AIN function block handles the
 318 43 Integrated Alarm Environment
scaling and associated alarm status. A typical data
block for an AIN function block is as shown on the
right hand side of Table 43.1.
The values in slots 1–11 will be discussed in
Chapter 45. It is sufficient to say that the measure-
ment of the level in a tank varies between 0 and
2 m, and its calculated value is stored in slot no
18. The contents of slots 12–17 all relate to alarm
handling as follows:
12 This defines the area menu of the group dis-
play which contains the template for LRC47.
Whenever the level goes into alarm, the OCP
will prompt/guide the operator to the relevant
area/alarm. This is typically realised by a ded-
icated banner line across the top of the dis-
play system which immediately identifies areas
with new alarms.
13 When an alarm occurs, it is automatically en-
tered into the alarm list and event log. The
alarm priority determines where it enters on
the list, as discussed below. The value of 0 in
slot 13 implies it has no priority.
14 The value in this slot specifies the upper alarm
limit. Whenever value in slot 18 goes above
1.8 m the alarm will be activated. This is obvi-
ously a warning that the tank is nearly full.
15 The value in this slot specifies the lower alarm
limit. The fact that a value of −0.1 m is speci-
fied,which can never be reached because of the
offset on the level measurement, implies that a
low level does not matter. It is common prac-
tice to set alarm limits at the end of, or outside,
the measurement range when there is no need
for an alarm.
16 A deadband of 0.05 m is specified. The pur-
pose of the deadband is to suppress the spuri-
ous alarms that would occur due to noise on
the level measurement when it is close to the
alarm limit.An obvious source of such noise is
waves on the surface of the liquid. Thus, once
an alarm has been triggered by the value for
the level rising above 1.8 m, the level will stay
in alarm until it has fallen below 1.75 m.
17 A message code is specified. Whenever an
alarm occurs, a specified message can be
printed in a reserved area of the OCP display.
Messages are typically stored in library files,
each message having a unique code. The code
of 0 in this case implies that there is no message
attached.
These alarm features are established when the
database is built. All other analogue inputs would
have similar data blocks. Similarly, all other signal
and variable types will have alarm features built
into their data blocks. Thus alarm handling crite-
ria will be dispersed throughout the database. The
DDC package will systematically apply the appro-
priate routines to these data blocks and, if neces-
sary trigger alarms. The OCP will then systemati-
cally display and log any alarms that are triggered.
43.2 Display Systems
The basic alarm handling functionality of most
computer control systems is broadly similar.
Whenever an alarm occurs, the following takes
place automatically and simultaneously:
• An audible alarm will be annunciated, typically
a buzzer, which the operator may acknowledge
and accept as appropriate.
• A message may appear in the reserved alarm
message area of the OCP display.
• The alarm will be entered into the alarm list and
thereafter its status monitored and the alarm list
entry kept up to date.
• A printout of the alarm will occur on the event
log.
• The area within which the alarm has occurred
will be highlighted on the banner line to assist
the operator in locating the relevant group dis-
play.
• Some feature of the relevant group display face-
plate will change. For example, the colour of a
bar will change to red, or some text characters
may start to flash.
• Similar colour changes and/or special effects
will occur on all relevant faceplates integrated
into the mimic diagrams.

43.3 Alarm Lists
These are structured lists which are kept up to date
in real-time. The essential features are as follows:
• Grouping of alarms on separate lists according
to plant areas.Whether this is necessary depends
on the size of the plant, the extent of the areas
and the number of alarms.
• Alarms within an area are grouped together ac-
cording to priority,the highest priority grouping
being at the top of the list.
• Within any grouping, alarms are listed in
chronological order, the most recent being at the
top of the group.
• The list entry consists of the tag no, description,
date/time of occurrence, type of alarm and cur-
rent alarm status.
• The length of the list will be constrained by the
no of entries or the time lapsed since occurrence,
as described for event logs in Chapter 42.
The above alarm handling functions form an inte-
grated alarm environment. They are built into the
system and happen as a matter of course. Funda-
mental to this are the alarm related values built
into the database.
43.4 Integrated Safety
Environment
An integrated alarm environment is concerned
with alarm handling only. It is not the same thing
as an integrated safety environment in which a va-
riety of additional functions may be supported.
Some of these functions may be more sophisti-
cated means of alarm handling. Others will enable
corrective action to be taken in the event of an
alarm occurring:
• Warnings. The data block for LRC 47 above sup-
ported a single pair of high and low alarm limits.
This is normal. However, some systems support
multiple limits on a single signal. For example,
there can be a warning band set within the alarm
band. These limits are referred to as Lolo, Lo, Hi
43.3 Alarm Lists 319
and Hihi. The Lo and Hi limits trigger a warning
but not an alarm.
• Alarm filtering. When large numbers of alarms
occur over a short period of time, it can be dif-
ficult to interpret them. Some systems provide a
filtering function. This effectively identifies crit-
ical alarms and suppresses others: suppression
being either a reduction in priority, a delay or
even deletion. Clearly the filtering criteria have
to be specified very carefully.
• Trips and interlocks. These are closely allied
to alarms, are defined in Chapter 55 and, typi-
cally, are realised by means of configurable logic
blocks. They take pre-defined corrective or pre-
ventative action in the event of an alarm occur-
ring. Trips and interlocks are used extensively
and, after alarms, are by far the most common
safety function supported by any system.
• Sequences. These can be used to carry out cross
checking,application diagnostics and automatic
shut-down. Sequence control was introduced in
Chapter 29.
• Expert systems. These have been used in an on-
line mode to provide decision support in rela-
tion to alarm handling. In essence, by analysing
the pattern of alarm occurrences, the expert sys-
tem attempts to deduce the underlying causes
and recommend appropriate actions. An intro-
duction to expert systems is given in Chap-
ter 107.
43.5 Alarm Management Policy
The purpose of an alarm management policy is to
ensure that the system generates alarms, warnings
and/or messages in as effective a way as possible
with regard to the operators.It is fairly obvious,but
often forgotten, that:
• Alarms, warnings and messages provided to an
operator must be sufficient to enable correct
analysis and /or diagnosis. Information that is
too sparse cannot be interpreted reliably.
• Alarms and warnings must be provided early
enough to enable timely intervention, if neces-
 320 43 Integrated Alarm Environment
sary. Alarms that occur too late are next to use-
less.
• The volume of information presented must be
such that the operator is not overloaded. The
term “deluge” is used to describe alarms that are
too many or too frequent for an operator to han-
dle meaningfully.
There are various strategies that can be used, the
most important being:
• Categorise alarms as being either global or lo-
cal in relation to the architecture of the control
system. For example, global alarms will be dis-
played throughout the system whenever they oc-
cur, whereas local alarms will only be displayed,
listed, etc. on the operator station used for the
area to which the alarm relates.
• Group and prioritise alarms, according to area,
priority,chronology, etc. as described previously.
• Minimise standing alarms. These are variables
that persist in an alarm state, albeit having been
acknowledged. This is often because the alarm
limits are inappropriate. It is good management
practice to review standing alarms on a regular
basis, to decide if the alarm is necessary and, if
so, whether its limits are sensible.
• Avoid duplication of alarms. There is much
scope for duplication, for example:
– An AIN block may generate alarms according
to predefined limits.
– Further alarms may be generated if the same
input signal goes out of range or, with smart
devices, if the transmitter goes out of calibra-
tion.
– There may be alarms in associated function
blocks, such as deviation alarms attached to
error signals in associated PID blocks and
range limits in analogue output (AOT) blocks,
as seen in Chapter 44.
• Prevent spurious alarms. Use of deadband to
prevent alarms due to noise, as described above
for slot 16.Such spurious alarms are bad practice
because they cause the alarm to fall into disre-
pute.
• Suppress known,predictable alarms such as dur-
ing start-up and shut-down.
• Provide operator support by means of alarm
filtering, acknowledgement records, application
diagnostics, etc.
The combination of strategies that is most appro-
priate for a given context depends on factors such
as the nature of the process and/or plant, the ex-
pertise of the operators, and the functionality of
the control system. It is essential that the alarm
requirements are thought through, properly speci-
fied, and reviewed regularly.
43.6 Comments
Many of the major control system vendors have
developed proprietary alarm management sys-
tem (AMS) packages, as described in Chapter 99,
which can be installed retrospectively on DCS and
SCADA systems. They provide much of the func-
tionality outlined in Section 43.4 and enable alarm
management policy as outlined in Section 43.5.
More sophisticated AMS packages are used for ab-
normal situation management (ASM).Whilst these
packages can make a major contribution to safety,
and it is certainly inappropriate to argue against
usage of such,their installation is tantamount to an
admission of failure. There is sufficient function-
ality in any DCS or SCADA system to cope with
any sensible alarm handling requirements without
the need for bolt-on packages. The problem is that
those requirements have to be properly thought
through at the specification stage and incorporated
in the detailed functional specification (DFS) as
appropriate. Unfortunately, that is a corner which
is cut all too easily and far too commonly in the
interest of expediency.