ECQ75Units5 6 All

Certificate in PLC’s and
SCADA Systems
Units 5 & 6
E-mail: eit@eit.edu.au Web Site: www.eit.edu.au
AUSTRALIA CANADA IRELAND NEW ZEALAND SINGAPORE SOUTH AFRICA UNITED KINGDOM UNITED STATES
7
Good installation practices
In this chapter, we will learn the following:
• Introduction to PLC installation

• PLC panel wiring
• PLC and field devices wiring
• PLC panel earthing
• PLC panel safety considerations
• Control room layout
7.1 Introduction
Proper installation of any electronic system is necessary for its reliable and safe working.
Lot of people will agree with this. In practice, there is a tendency to overlook this
important aspect!
As a thumb rule, you will find installation guidelines along with every PLC system.
Since the contents are given in complex technical terms, they are overlooked.
They are not as complicated as they seem to be.
Let us first learn some of the concepts related with the PLC installation procedures.
7.1.1 Interference and noise

Interference or noise is an important factor to consider in the overall design and
installation of the PLC system. Noise can be defined as the random generated undesired
signal that corrupts (or interferes with) the original (or desired) signal.
The ratio of signal voltage to noise voltage determines the signal strength in relation to
the noise. This is called Signal-to-Noise ratio (SNR) and is an important consideration
while designing electronic systems where electrical interference can be a problem.
The SNR is usually expressed in dB, which is the logarithmic ratio of the signal
voltage to noise voltage.
SNR = 10 log S/N (measured in decibels)
70 Automation and process control using Programmable Logic Controllers
7.1.2 Sources and types of noise

Noise is normally introduced into the signal circuits through electrostatic (capacitive)
coupling, magnetic (inductive) coupling and resistance coupling. Arguably, a fourth
category of noise is electromagnetic interference due to radio interference.
As this is mainly manifested as a near field phenomena (such as electrostatic and
magnetic coupling) this will not be considered. The reduction of these noise signals takes
the form of shielding and twisting of signal leads, proper grounding and separation.
Shielding: By definition, it is the protection of the signal wires from noise of unwanted
signals (see Figure 7.1).
Figure 7.1
A typical shield
The purpose of the shield is to reduce the magnitude of the noise coupled into the low-
level signal circuits by electrostatic or magnetic coupling. This has brushed up the above-
mentioned concepts up to some extent. Let us focus once again to the installation
requirements for different sections of a PLC system.
We will refer to the following typical PLC system schematic diagram for
understanding the installation requirements (see Figure 7.2).
Good Installation Practices 71
Figure 7.2
A typical PLC system
We will divide the installation requirements of a PLC system in the following areas:
• PLC modules
• PLC rack
• PLC panel internal wiring
• PLC panel power supply
• Cabling between PLC and field devices
• Cabling between PLC and control room computers
• PLC earthing
• Specific PLC installation requirements
• Control room requirements
Now we will discuss the installation requirements in each area.
7.2 PLC modules

While installing PLC modules, a good amount of care should be taken because it is the
most delicate part in the entire system. For non-floating inputs and output modules,
connect terminal M of the load power supply to PE ground conductor of the control
circuit. Similarly, the following installation features can be employed.
7.2.1 Keying of module

This is an important technique to avoid the situation where maintenance personnel
replace an I/O module that has failed with the wrong module. Installing some form of
keying mechanism (which is unique to each type of module supplied by the particular
manufacturer) on the back plane prevents inadvertent errors of this nature.
7.2.2 Handling of memory chips

Special care should be taken in handling memory chips for the PLC. They are very
sensitive to static electricity and are easily damaged. The following installation rules
should be followed:
• Prior to handling the RAM chips, avoid handling any materials that can
build up static charges (such as cellophane covered items).
• Always wear a anti-static wrist strap that has been securely
grounded
• Ground all tools before contacting the RAM chip
• Keep relative humidity in the work area to between 40-60
percent RH
• Eliminate all carpeted areas in the workplace that can build up
static
• Do not touch the chip pins (only the chip base)
• Ensure careful alignment of the pins before installation of the
memory chip into the chip socket
If there is any valuable data on the chips, back up this information onto floppy or hard
disk.
7.2.3 Selecting voltages for I/O modules

This refers to the voltages used for the PLC to perform its actual digital input and output
control (and its interface to the various items of equipment).
Typical considerations for selection of voltages to use in a PLC installation are:
Standardization
If an area of the factory or plant is already standardised on the voltage (such as 110
VAC) then it makes sense from maintenance and spares point of view to continue with
this approach.
Voltage range of input/output module

It may be that a particular PLC has already been selected and only supports a particular
voltage level.
Minimization of power consumption/heat generation

A low voltage such as 24 VDC may be preferable when the power dissipation of an I/O
module has to be minimized, as less current will be used here.
Leakage current/earthing and grounding problems

If the wiring is of such a poor standard that ground loops are forming, the voltage used
should be of such a level that they are well above spurious voltage and currents that may
develop in the circuit due to these problems.
Voltage range
Ensure that the particular voltage selected is matched to the range of the input/output
modules and there is a margin of safety. For example, if the range is 0-48 VDC and the
input module selected has a range of 0-50 VDC, this will be inadequate if 48 VDC is
sourced from a lead-acid battery system, which, when fully charged, have a voltage of 51
V.
Indeterminate state
When using certain sensors, there may be some leakage current even when the device is
off. This can tend to bias the input channel into the ON condition even though the device
has been switched off. An example of devices; exhibiting this problem are proximity
detectors. The voltage range should be checked to see whether this is a problem for a
particular input with its associated sensor.
Loop powering of field devices

Some field devices require an external voltage source to power them. This voltage is
often derived from the modules and should be compatible (e.g. 24 VDC).
It should be noted that in today’s world, from an analog point of view, there is not
much argument about using 4-20 mA for the interface. The low impedance 4-20 mA
analog signal is relatively noise immune when compared with high-impedance voltage
signal systems.
Some of the older standards may still be 0-10 V/10-50 mA or 0-20 mA, but they are
not as common as the 4-20 mA standard.
Sometimes, a voltage interface standard may have certain advantages over the 4-20
mA standard (such as lower power requirements). The zero of the range is selected to be
4 mA and is useful as anything less than 4mA indicates that there is a problem (such as a
broken wire).
Interestingly, a 4-20mA is related and associated with the older pneumatic standard 3-
15 psi by having the same ratio (1:5).
7.3 PLC rack

Since all modules get their power supply from either backplane connectors or slots on the
rack, its grounding and earthing is important. For every PLC rack, a grounding screw is
normally provided on the rack enclosure.
The same should be connected with copper conductors of at least 10 sq. mm cross
section radially by the shortest possible route to a central grounding point to protect
against stray noise.
For non-grounded operation, connect the mounting rack of the PLC through a capacitor
to the ground potential (to divert the radio frequency interference).
In addition, any electromagnetic interference coupled into the PLC via signal and
supply lines are dissipated by connecting to the central grounding point on the rack.
Connect the central grounding point using a copper conductor of at least 10 sq. mm
cross section to the PE protective ground conductor by the shortest possible route.
Connect the PE conductor of supply line of rack to the PE terminal on the rack if
provided.
7.4 PLC panel internal wiring

Generally, in a typical PLC panel we will find cables used for the following lines:
• Supply line for PLC and load power supply units
• Digital input/output signal lines for AC (110 V/230 V or else).
• Digital input/output signal lines for DC (24 V/110 V or else).
• Analog signal lines (4-20 mA, 0-5 VDC, or else 0–10 VDC )
The following rules should be followed with wiring arrangement inside cabinet:
• Analog output signal lines and digital signal lines can run unshielded in the
same cable duct.
• Only shielded analog input signal lines can run with digital signal lines in
the same cable duct.
• Neither digital signal lines for DC (24VDC or else) nor analog signals (4-
20 mA, 0-5 VDC, 0-10 VDC) should run with AC lines in the same cable
duct.
• All shields of signal cables must be grounded on module terminals
provided.
• Use metal enclosures for mounting all PLC equipment. This provides a
medium of screening from sources of electrical noise.
7.5 PLC panel power supply

The PLC panel power supply is used for following purposes:
• Supply power to PLC rack consisting modules.
• Supply power to load power supplies (field interrogation power supply).
• Supply power to lighting and other utilities inside panel.
Generally, separate MCBs (miniature circuit breakers) are provided for individual units
so that, in the event of a breakdown of individual equipment, only that equipment gets
isolated from the main power supply.
Ensure that the AC power source for the PLC system is isolated (through a constant
voltage transformer or isolation transformer if possible) from any sources of electrical
noise.
For PLC installations near sources of electrical interference, an isolation transformer is
a recommended approach. Note that the output devices being controlled should draw
power from the original source of the voltage unless the secondary of the isolation
transformer (which is supplying the computers) has been specifically rated for these
additional devices.
Where the AC power source has variations, a constant voltage transformer (CVT) can
stabilize the voltage for short periods of time, thus minimising shutdowns. It is worth
noting here, that CV transformers are very sensitive to variations in mains frequency and
will not operate successfully with unstable mains frequency supplies (see Figure 7.3).
For both the CVT and the isolation transformer the operating
frequency and the operating voltage should be carefully specified (e.g. 240VAC + 10%-
15% or 50Hz ± 2%).
Figure 7.3
An isolation transformer
It is important to size transformers correctly:

• If the transformer is too small, it will clip the peaks off the sine wave (due
to saturation) resulting in a lower RMS value of the voltage. The power
supply could sense this as a low voltage and shutdown. The transformer
may also overheat and burn out.
• Excessively large transformers do not provide as much isolation as a
correctly sized transformer, due to higher capacitive coupling.
Where power supply is variable in frequency, or unreliable, or where the PLC requires
high power supply security, the UPS (uninterruptible power supply) is often selected. Its
size in KVA rating is decided as per the system load.
An online UPS converts raw AC power into DC voltage by first using a rectification
unit and then coverts the same DC voltage into AC using an inverter unit and feeds the
same to the load. In the event of power failure of raw AC, it starts taking DC voltage
through batteries and converts into AC, and feeds the same to load.
Useful techniques to reduce the electromagnetic interference and switching transients
are given in Figure 7.4.
Figure 7.4
Techniques for reducing electromagnetic interference and surges
7.6 Cabling between PLC and field devices

The following thumb rules must be followed for cabling between PLC and field devices:
• Analog output signal lines and digital signal lines must run in separate
cables.
• If you expect a higher interference, then run the digital AC, digital DC and
analog signal cables in separate cable ducts.
• Maintain a clearance of at least 10 cm between signal and power cables
over 500 V.
7.6.1 Shielding wire

It is theoretically possible to almost eliminate both electric and magnetic field noise (and
hence, the need for shielding) by using twisted pair signal cables. Magnetic interference
reduction can vary from a factor of 14 for four-inch lay (or three twists per foot) to 141
for one-inch lay (or 12 twists per foot).
Electrostatic coupling can be reduced by a factor of 103 for copper braid (with 85%
coverage) to aluminium Mylar tape with a factor of 6610. These shielded wires are
normally ineffective for magnetic coupling; hence, twisting of the pairs is also desirable
within a shield.
It is important that the shield is earthed (or grounded) at one point only, so that all
ground loops are eliminated. This means that the shield envelope should have an
insulated jacket so as to prevent multiple grounds.
Ground loops in signal wires can be eliminated by decoupling the input amplifier (as in
Figure 7.5) or using optically isolated signals (as in Figure 7.6). This is sometimes
referred to as Galvanic Isolation.
Figure 7.5
Transformer - coupled input
Figure 7.6
Opto-electronic coupler circuit
7.6.2 Cable spacing

In the practical world, with many different cabling systems in a particular plant, a system
has been developed to classify all wirings in a certain class of susceptibility to
interference and to group the classes in an orderly manner as indicated below.
Some points to emphasize when installing cabling are listed below:
• Calculate the actual distance the cable is being run – i.e., both the
horizontal and vertical distances. Select the shortest possible path away
from sources of noise.
• Route the cables well away from potential sources of electrical
interference, harsh chemicals, excessive heat, wet environments and
sources of physical damage.
• Ensure that no one will walk or drive on the cable.
• Ensure that the cable is not put under undue tension (such as hanging
between two points).
• Do not bend the cable excessively in the installation process.
• If the cable is likely to run a considerable distance, a calculation should be

made of the IR drop along the wire to determine whether it is excessive.
Hence, a higher voltage may be required if the cable resistance is high or
the distance over which the cable run is fairly lengthy.
7.6.3 Wiring levels

There are four basic levels or classes of wiring that can be identified. The IEEE 518
standard defines four levels:
• Level 1 - High Susceptibility
Analog signals of less than 50V and digital signals of less than 15V.
• Level 2 - Medium Susceptibility

Analog signals greater than 50V and switching circuits.
• Level 3 - Low Susceptibility

Switching signals greater than 50V, analog signals greater than 50V, regulating
signals of 50V with currents less than 20A, and AC feeders less than 20A.
• Level 4 – Power
AC and DC power buses of 0-1000V with currents of 20-800A.
7.6.4 Wiring class codes

Within a level, conditions may exist that require specific cables and regrouping is not
allowed. This condition may be identified by a class coding system, similar to the
following:
• A analog inputs, outputs
• B pulse inputs
• C contact and interrupt inputs
• D decimal switch inputs
• E output data lines
• F display outputs, contact outputs
• G logic input buffers
• S special handling of special levels may require special spacing of
conduits and trays, such as signals from commentating field and line
resistors, or signals from line shunts to regulators, or power > 1000V or >
800A, or both
• U high voltage potential unfused greater than 600VDC
7.6.5 Tray spacing

The tables from the IEEE 518 are given below. Table 7.1 indicates the minimum distance
in inches between the top of one tray and the bottom of the tray above, or between the
sides of adjacent trays (also see Table 7.2 and 7.3).
LEVEL 1 2 3 3S 4 4S
1 0 11 6 6 26 26
2 11 0 6 6 18 26
3 6 6 0 0 18 12
3S 6 6 0 0 8 18
4 26 18 18 8 0 0
4S 26 26 12 18 0
Table 7.1
Tray spacing (inches)
LEVEL 1 2 3 3S 4 4S
1 0 1 4 4 18 18
2 1 0 4 4 12 18
3 4 4 0 0 0 2
3S 4 4 0 0 6 12
4 18 12 0 6 0 0
4S 18 18 8 12 0 0
Table 7.2
Tray - Conduit spacing (inches)
LEVEL 1 2 3 3S* 4 4S*

1 0 1 3 3 12 12
2 1 0 3 3 9 12
3 3 3 0 0 0 6
3S 3 3 0 0 6 9
4 12 9 0 6 0 0
4S 12 12 6 9 0 0
Table 7.3
Conduit spacing (inches)
7.7 Cabling between PLC and control room computers

Cabling between the PLC and control room generally involves communication cables
(data exchange) and power supply cables.
Communication cables are special cables selected as per mode of communication (for
example PROFIBUS, MODBUS, Ethernet RJ45 or fiber-optic cable, etc.).
Since they are special, delicate cables carrying low-level signals, they should be
installed carefully as per the following rules:
• Run the communication cable and power cable in separate cable ducts.
• Select the shortest possible route that is away from sources of noise.
• Route cables well away from potential sources of electrical interference,
harsh chemicals, excessive heat, wet environments and sources of physical
damage.
• Ensure that no one will walk or drive on the cable.
• Ensure that the cable is not put under undue tension (such as hanging
between two points).
• Do not bend the cable excessively in the installation process.
• If possible, take the cable through a metallic conduit of suitable size, with
the conduit grounded at one point.
7.8 PLC earthing

The earth (or ground) is defined as a common reference point for all signals in the
equipment situated at zero potential. Below 10 MHz, the principle of a single-point
earthing system is the optimum solution.
Ensure that all hardware is securely earthed. The earth electrode is the central point for
all electrical equipment and AC power within the facility. Use maximum size copper
wire (say, 8 AWG) for the earth.
Three types of earthing systems are indicated in Figure 7.7. The series single point is
perhaps the more common, while the parallel single point is the preferred approach with
a separate earthing subsystem for groups of signals:
• Safety or power earth
• Low-level signal (or instrumentation) earth
• High-level signal (motor controls) earth
• Building earth
Particularly when a PLC system is improperly grounded, then it can behave erratically
and may get destroyed.
The problem of ground loops arises when different devices are earthed at different
earthing points (see Figure 7.8).
Figure 7.7
Various earthing configurations
Figure 7.8
Ground loop
To avoid it, tree-type configuration is preferred where all separate components are
connected to a common line first, and then that common line is connected with earth
point.
To avoid ground loops:
• Each PLC module chassis should be grounded with the main PLC chassis.
• The PLC chassis or rack should be grounded in turn to the back plate or to
the ground connection.
• Ensure that the panel enclosure is connected to ground point.
• The ground connection should have least resistance value (< 0.1Ω).
A PLC system particularly has a panel earth, an instrumentation signal shield earth and
a power supply earth.
Instrumentation earth and power earth should be taken from separate earth pits. All
signal shields must be grounded at one end in the case of digital and analog signal cables.
The shield must be grounded at both ends for other data cables such as:
• Connecting cables between central PLC rack and extension racks
• Bus cables
• Cables to peripherals
As discussed in the earlier individual sections, grounding has to be provided for all
necessary equipment.
7.9 Specific PLC installation requirements

There are a few specific requirements for the installation of PLC systems. For inductive
loads such as electromagnetic relays, it draws an excess amount of current when it is
turned on and there is a power surge when it is turned off. Surge suppressor can protect
equipment from voltage spikes caused by inductive loads. These are discussed in the
following sections.
7.9.1 Reed relays, electromechanical relays and solenoids (DC only)

DC relays are often used in PLC panels, nowadays for isolating PLC digital inputs or
digital outputs from field devices. As the actuator mechanism of these loads is an
electromagnetic coil with a large inductance, it is a good practice to use a freewheel or
shunt diode across the relay control terminals when de-energizing the coil by switching
off the digital output. When the coil current is removed, the back EMF generated by the
energy in the coil is dissipated in the diode's current path. Otherwise the back EMF
builds up on the digital control line and may damage the digital output. Some relays
have built in freewheel diodes.
Similarly, if the relay is driving an inductive load, it is a good practice to protect the
relay contacts from arcing and being damaged by the back EMF from the load by placing
a freewheel or shunt diode (and possibly, a resistance to dissipate energy) across it.
Other than open collector outputs, digital lines are not generally capable of driving
relays. Buffering them with a driver chip is thus necessary. For example a ULN2003 may
be used (see Figure 7.9).
Figure 7.9
Driving relays and preventing back EMF damage
7.9.2 Solidstate relays

These are relays where the output switch is fabricated from power semiconductor devices
and the control inputs behave like transistors. The control input may need buffering if
the current requirements exceed the digital drive available, but there are no back EMF
problems to deal with.
Back EMF from an inductive load may be reduced by a snubber network as shown in
Figure 7.10.
Figure 7.10
Driving solidstate relays
7.9.3 Switch inputs

As switches are passive devices with no power source, one side of the switch must be
pulled up or down (with a suitable resistor) to the logic level (+5V usually is normally
available from the host card) or ground and the switch position is read by the digital
input.
Two such connections are shown in Figure 7.11. The first should give better noise
immunity and has the advantage that one terminal is connected straight to ground --
useful if the system is made from a conducting metal and is at the ground potential -- one
does not need to have a ground return wire from the switch.
Figure 7.11
Reading the position of a switch
7.9.4 Fuses
It is always good practice to fuse the output module channels. This ensures that if the
normal load or inrush currents are exceeded, the output channels are protected from
damage. The manufacturers select fuses with certain current/time characteristics for use
with their output modules only. These fuse types should be used. A good indication as to
whether a fuse has blown on some output module is an individual "blown fuse" light.
Most good output modules will have an individual "blown fuse" light for each circuit.
7.9.5 Interposing relays

These are useful in circumstances where the load to be controlled has far greater current
requirements than the output module can deliver. For example, we would use an
interposing relay to control a larger relay, which is rated for the load's voltage and
current.
This may be preferable to using a different model higher rated output card, with an
attendant extra costs for a few circuits.
7.9.6 Safety circuit

The National Electrical Manufacturing Association (NEMA) and other authorities
recommend the use of emergency stop function hardware to be independent of the PLC
software and solidstate electronic construction.
Two of the biggest areas of concern as far as safety are concerned are one, the
behaviour of the software (especially during preliminary commissioning) and two, and
the solidstate output devices. Many solidstate output devices fail in the shorted condition
7.10 Control room requirements

The majority of tasks in a computer control room can be broken down into the following:
• Monitoring of the system
• Control adjustments
• Alarm/emergency procedures
• Staying awake
A few issues to assess in the design of the control room are:
7.10.1 Environmental considerations

The environment in which the system is installed must be appropriate to the computer
system and the associated electronics systems. Typical environmental conditions that are
considered suitable for the standard and the industrial environment are listed in Table
7.4.
Obviously, the environment in a control room should not have these extremes. The
equipment should be rated for these ranges. Typical control room environmental ranges
are discussed under ergonomic requirements. Industrial computer systems may be
mounted in a less stringent environment than for the standard airconditioned control
room.
ENVIRONMENTAL RECOMMENDED RANGE

CONDITION
INDUSTRIAL STANDARD
Operating Temperature 0°C to 60°C 0°C to 50°C
Storage Temperature -40°C to 85°C -10°C to 60°C
Relative Humidity 5 to 95% RH 5 to 90% RH
Table 7.4
Environmental conditions
Should the operational personnel believe that there could be problems with the
environment having excessive dust, corrosive vapours, moisture or oil, the best approach
is to mount the computer system in an enclosure. This will provide the necessary
protection for the processor.
Special consideration may have to be given to such issues as vibration and it may be
necessary to mount the computer in the enclosure on shock mountings to absorb some of
the vibration.
Ensure that the enclosure doors can be easily opened and heat is allowed to dissipate.
Note that hot air rises and there can be a build up of air inside the top of the enclosure
and a fan may be needed to circulate the air.
7.10.2 Typical control room layout

A typical layout is given in Figure 7.12.
The ‘Horseshoe control room’ layout is designed so that anyone in a center can see all
the screens. Operators at any of the operator displays should be able to view the entire
control room's screens without undue difficulty as well.
Although the focus in a control room is normally on the equipment and computers, the
amount of space for the operators should be maximised to avoid congestion (particularly
when there is a changeover of shifts). Operators will spend a considerable amount of
time in from of their consoles and the layout should ensure that the operator can see
anyone coming into the control room and not have people peering over their shoulders.
Similar areas in the system that are being monitored should be situated close together
to avoid unnecessary movement by the operators to see what is going on.
Figure 7.12
Typical layout of the computer control room
The voice communications system (either radio or telephone) should be situated as

close as possible to the operators and for other persons entering the control room. For the
control room indicated in the diagram, at least three internal telephones should be
provided for easy access (with frequently used numbers programmed into the system).
The amount of desk space should not be compromised. Space should be allowed for
manuals and other items to be left on the desk without unnecessary clutter.
Printers for the system are situated in a separate room to isolate the operators from the
associated (rather, repetitive) noise. The associated inconvenience of having to walk to
the printer room to view alarms can be minimized by providing on-screen alarm reports.
A ‘separate meeting room’ should be provided to avoid holding meetings in the control
room which are of no interest to the operator but which disrupt his work.
The following specific issues should also be considered in the design of the computer
control room.
7.10.3 Lighting
Tungsten halogen light sources produce warm lighting, while the light life of 2000 to
4000 hours is reasonable. They are not diffused and can produce significant shadowing.
If longer life is required, tubular fluorescent lamps have a life of 5000 to 10000 hours,
but may have variable colour rendering and variable apparent colour if the correct colour
tube is not chosen.
The luminaries should be fixed overhead and provide direct lighting. Desk lighting can
be installed to provide localized lighting over the keyboard.
A general level of lighting of 400 lux is recommended throughout the control room
with a personal level of 200 to 600 lux set by the operator.
An average reflectance level of 30-60 percent is recommended for the walls. The
ceiling should have a reflectance of at least 75 percent, with floors an average of 40
percent.
7.10.4 Sound environment

A maximum noise level of 54-59dB (A) is recommended.
7.10.5 Ventilation
The air temperature should be between 20°C and 26°C with relative humidity range of
40-60 percent RH. Fresh air should flow at the rate of 7 litres/sec per person throughout
the control room.
7.10.6 Colours of equipment

Colours for walls and equipment should have a matt finish (i.e., no shiny surfaces) to
avoid irritating reflections from the operator displays.
Strong contrasts in colour should also be avoided to minimise glare. Matt or "orange
peel" finish help to disguise inevitable blemishes and ripples in flat sheet metal surfaces.
A glossy "contours d'elegance" finish will cost extra and is unlikely to survive rigours of
transport from factory to job site.
Where the general light level is low (less than 300lux) warm color schemes are more
acceptable than those in which cold colors predominate. A pleasant colour scheme can be
achieved with warm colours backed up with cool secondary colours.
These are typical installation requirements that should be taken care of. Further
additions for improvisation are still possible.
19
Best Practice Documentation
‘The project is on its last run towards home; the conflicts of the design phase are now a memory, and the ulcers of
the procurement phase have stopped hurting. The panics of construction are almost over and any day we’ll be
commissioning the plant. What else is left to do?
Ah, yes—the equipment manuals.
Who in the design team isn’t busy? Good old Jan and Bill are free. They should be able to rustle up something
before commissioning is finished. They’d better be careful though, because there’s not much money left in the
budget…’
Sound familiar? Yes, there was a time when it wasn’t unusual for manuals to be almost an
afterthought—something that a manufacturer, engineer or contractor saw as an annoyance, separate
from the product itself. And why not? Before solid state electronics, clients bought their process
controls as more or less standard units. Regardless of the manufacturer, the units operated in much the
same way on well-known pneumatic or electrical principles. If the manuals were poor, no matter, since
the engineer, maintainer or operator had experience of similar control units. And in the extreme, you
could always pull the unit apart to see how it worked.
But no more. For one reason, process controls are more intricate and operate on a greater variety of
physical principles; there’s simply more for clients to learn. For another reason, even similar units of
electronic hardware can require you to be initiated into an esoteric club of codes and jargon before you
can use them.
So the days of half-hearted documentation efforts are long gone. Clients of the 90s know that good
manuals save money, and they’re prepared to evaluate manuals along with other quality attributes of the
equipment they buy. They seek sophisticated, highly engineered documents that match the technology
and quality of the products they describe, whether those products be individual items
of equipment or complete process plants.
{PA
A good manual —
• Tells readers what they want to know.

• Tells them — all of them! — in a way they can understand.
• lets readers find things easily.
The following pages set out the basic steps in the production of manuals of good quality.
19.1 What is a Manual?

In this workshop, manual is just a word for any form of documentation. Of course, the most common
packaging is still in the form of printed words on paper, bound as a booklet, a book or a loose-leaf ring
binder. But processor-driven hardware such as PLCs and computers offer a newer form: online manuals
that you can access on screen with a few keystrokes.
Which is better—paper or screen? The answer is neither, since each has its advantages, and increasingly
manufacturers are supplying both where they can.
Paper manuals These are readable anywhere including in bed. Readers feel comfortable with
them, and having used books from childhood, they don’t need special instructions for using them.
Books allow you to add information by scribbling in the margins and by adding pages, and you can
stick your fingers in one part of the book while quickly flipping to another (though it must be said that
the
software underlying modern online manuals is catching up fast in this respect!)
But paper manuals can get separated from the hardware they describe, so that often they’re not around
when needed. And large manuals need good indexes for finding unusual topics.
Online manuals These are part of the hardware, and so can’t get separated. Being electronic
they offer global searches to find topics quickly. Recent versions go further by using hypertext to make
their information hierarchical: readers start reading the most general text, then select important words if
they need more detailed information.
Most online manuals now have three levels of help:
• Memory-jogging help, usually as one line at the bottom of the screen, telling the reader his
immediate options (for example, Tab to item you want, and press Enter key).
• Context-sensitive help that gives the reader more detailed information about what he’s doing at
the moment, and lets him jump to related topics if he needs.
• Comprehensive help on all topics, with the topics listed alphabetically like a mini-index.
But online manuals always have the weakness that they are only for process or-driven hardware.
Furthermore, for all their advantages, they still aren’t as intuitive as paper ones and you still need to
give instructions for using them—hence their first section is usually called Getting Help on Help.
19.2 Types of Manuals
In the process control industry there are at least seven types of manuals, each serving a distinct purpose.
(The naming convention for the various types of manuals is not universally adhered to; part of the
reason is that many manuals serve more than one purpose. In the discussion that follows, the manual
names are those most commonly given to the seven purposes.)
Who creates which manuals? The answer depends somewhat on the way a process plant comes into
being. A common scenario is:
1 A process plant operator (the client) wishes to build a new process plant.
2 The client contracts with an engineer-constructor to design and construct the new plant, making
the engineer-constructor responsible for the suitability of the detailed design, but with the client having
final approval of the broad design principles.
3 In the course of designing process controls, the engineer-constructor designs a broad system,
and specifies the system requirements. A contract is then awarded to a controls supplier to manufacture,
supply, install and commission the controls in
accordance with a detailed system design created by the supplier. In this scenario, the supplier also
contracts to train senior operators while the new plant gets going.
4 The supplier manufactures and supplies the system components, and subcontracts the
installation to an installer. The installer follows instructions in the supplier’s documentation:
• P&IDs (Piping and Instrument Diagrams),

• construction drawings, and
• installation manuals.
5 When the control system is ready to run, the supplier provides a commissioning engineer who
supervises the commissioning. The installer’s people do the actual work of commissioning. Both the
commissioning engineer and the installer’s people follow
procedures in the supplier’s commissioning manuals, of which there may be two types:
• individual standard manuals for individual standard components, and

• a system manual written specifically for the client’s system.
6 As a final step in the installer’s subcontract with the supplier, the installer gives the supplier
copies of the documents that have been created for the purpose of, or in the course of the installation;
these usually consist of detailed construction drawings,
revised to show as-constructed details.
7 Around commissioning time, the supplier’s training engineer trains the client’s senior operators
in operating the new plant. The operators learn from the supplier’s training manual and by hands-on
instruction.
8 As a final step in the supplier’s contract with the engineer-constructor, the supplier gives the
engineer-constructor copies of the following types of documents:
• design calculations,
• system schematic drawings,
• P&ID drawings,
• construction drawings, revised to show as-constructed details,
• installation manuals for individual standard components,
• testing, inspection and commissioning reports,
• system manuals describing the overall system and its subsystems,
• component manuals describing individual components and how they work,
• setup manuals for individual standard components and for the overall system,
• maintenance manuals for individual standard components and for the overall system,
• training manuals for the overall system, and
• operation manuals for individual standard components and for the overall system.
9 As a final step in the engineer-constructor’s contract with the client, the engineer-constructor
gives the client copies of the documents listed in the previous step.
Here, then, are the seven types of manuals referred to earlier. As you can see, they slot fairly neatly into
two broader groups, commonly called engineer manuals and operator manuals.
Engineer Manual Created by Followed by Purpose is to explain...

or Type
Operator
Installation Supplier Installer How to install the control system
Commissioni Supplier Supplier’s How to commission the control system

ng commissioning
engineer
Engineer System Supplier Engineer- How the control system components are
constructor arranged and interfaced to each other
Client’s plant
engineer
Component Supplier Client’s plant What each component does, how it
engineer works, what it looks like, and its
specification
Setup Supplier Client’s plant How to change the settings of the
engineer components, either by programming or
other means, to vary the way they work
Maintenance Supplier Client’s plant How to troubleshoot the control system
engineer and its components
How to repair faulty components
Operator Operation Supplier Client’s operators How to operate and control the system
and its components day-to-day to get the
best results from them
How to troubleshoot operating faults
Engineer manuals are those used by an engineer to keep a plant’s control systems in working order
(maintenance) and to change their general long-term settings to vary the way the systems work (called
setup or programming, depending on the nature of the system).
Operator manuals are those used by an operator to control the detailed short-term way the plant
works, in order to get the best results from it.
19.3 Planning the Manual

The basic steps in planning a manual are:
• Define your reader

• Define the contents
• Plan the illustrations
• Structure the manual
• Produce a dummy manual
• Look at your source data
• Plan schedule and personnel resources
19.3.1 Define your reader
Example: Your job is to plan a manual for the database in the data acquisition system XYZ.
To help you decide what readers want to know you need to know who they are. To find out, you build
pictures of several different typical readers (it is important that you do this for the expected range of
readers):
• level of education,
• qualifications,
• job description,
• life experience, and so on.
You then go a step further and redefine a range of experiences for these prototype readers, giving you a
measure of the least and the most each type is likely to know. The range of experiences might be
something like this:
• Has never used a computer

• Simple wordprocessing, without formatting
• Generally computer literate. Has used applications other than wordprocessors, but not a
database
• Has entered data in other databases, but not XYZ
• Has viewed data in other databases, but not XYZ
• Has used an XYZ database
• Has programmed in another database
• Has programmed in an XYZ database
Looking at this list, you probably decide that the knowledge levels are diverging too widely, and that
you may need to write three manuals for different categories of users:
• ‘Getting Started in Databases’ for inexperienced operators

• ‘Operating the XYZ Database’ for operators with some experience
• ‘Setting Up the XYZ Database’ for engineers
You can now create a table of the minimum and maximum experience levels of the reader for whom
each manual is suitable.
‘Getting Started in ‘Operating the XYZ ‘Setting Up the XYZ
Databases’ Database’ Database’
Max levels
Min levels Max Min Min levels Max levels
Readers experience levels levels
Has never used a

computer
Simple wordprocessing, z z z z z
without formatting
Generally computer z z z z
applications other than
but not a database
Has entered data in other z z z

databases, but not XYZ
Has viewed data in other z z z

databases, but not XYZ
Has used an XYZ database z z
Has programmed in z z
another database
Has programmed in an z
XYZ database
From the table we see that the manual ‘Getting Started in Databases’ assumes that the reader has at least
some simple wordprocessing experience (the minimum level). The top end of the range of readers who
would benefit from reading this manual are those who have no more database experience than having
viewed data in a non-XYZ database. Conversely, this means that a reader with more than that maximum
experience would probably get nothing from reading ‘Getting Started in Databases’ and would be better
starting with ‘Operating the XYZ Database.
Of more immediate benefit to us is the fact that we can now use the table in the next step of the planning
process: in defining the contents.
19.3.2 Define the contents
Much of what has to go into a manual is usually perfectly obvious, but it is worth making this step a
distinct part of the exercise, and to document it right from the start. More likely than not you will be
revisiting this spot later on, and any information you record now will help you later.
Using the table in the previous section, decide what material will be appropriate for the manual. Make a
note of your reasons for including it. Record also why you are not including certain material; you can to
pass these notes on to the reviewers along with the draft, as they may well raise the same questions.
19.3.3 Plan the illustrations
What illustrations will you need? Can you do them yourself? Is it cost-effective to do so?
Make sketches of the illustrations as you think of them. Don’t assume that the technical drawings
already available are all you need. Such drawings are usually quite unsuitable for the purpose of
communicating concepts: they are too busy and too concerned with showing everything—they are
perfect appendix material.
Technical writers know that a good picture really does say more than a thousand words, and they spend
a great deal of their time with technical illustrations, sketching them, reworking them from construction
drawings, or briefing professional illustrators to do it for them. Considering some of the direct benefits
of good manuals (for example, in terms of increased safety, or reduced down-time) shows that this is
time well spent.
19.3.4 Structure the manual
The two groups of manuals defined earlier share many of the principles described in this chapter, but
they vary in their structure, and in the separate emphasis they give to some topics. By way of example,
we will now look at the typical structures for two manuals written for the same component: a
programmable controller system for the fuel supply of a coal-fired boiler.
To understand the different structures of the manuals, it helps to know a bit about the fuel supply. The
boiler is fed with pulverised coal from four parallel coal mills, themselves fed by four variable-speed
belt feeders from four raw coal bunkers. The programmable controller receives a demand-for-coal
signal from the BAC (Boiler Automatic Control system). In response to the signal, the controller varies
the coal flow by either varying the speed of one or more feeders, or starting or stopping feeders.
Figure 19.1
An operator monitors the system in a central control room. Three control modes are available:
• automatic control by the programmable controller,

• local manual control at the control room console, or
• local remote control at the individual motor drives of the mills and feeders.
These, then, are the structures of the two typical manuals that good documentation practice might
suggest for such a control system:
ABC Programmable Controller System ABC Programmable Controller System
constructed for XYZ Power Plants Pty Ltd constructed for XYZ Power Plants Pty Ltd
Engineer's Manual Operator's Manual
Table of Contents Table of Contents
1 Introduction 1 Introduction
2 System Configuration 2 What the Fuel System Does
3 Installing the Controller 3 How the Fuel System Works
4 What the Controller Does · General
5 How the Controller Works · Starting Sequences
6 Starting the Controller · Normal Operation
7 The Principles of Programming · Abnormal Operation
8 Programming the Controller · Stopping Sequences
Using the Read/Write Loader 4 The Control Console
9 Programming PROM Memory 5 Now to Choose the Operating Mode-
10 Programming the Controller Automatic, Local Manual, or remote
Using the Loader/Monitor Manual
11 Monitoring 6 Automatic Operation
12 Troubleshooting 7 Local Manual Operation
13 Maintenance 8 Remote Manual Operation
14 Tutorial for Programming 9 Starting
Appendices: · Black Start
A Controller Codes · Normal Cold Start
B Controller Specifications · Normal Hot Start
C Schematic Diagrams of the 10 Stopping
System · Normal
D Wiring Diagrams of the System · Emergency
E Inspection and Test Certificates 11 Emergency Procedures
12 Safety Procedures
13 Troubleshooting
Appendices
A Schematic Diagram of the System
Draw up your own Table of Contents based on the work you did earlier (see Define the contents). Once
again, be prepared to revisit and restructure if the need arises. Reworking the structure may be easier
than trying to make the material fit an awkward structure.
19.3.5 Make a dummy manual
Make a dummy manual. This step is often omitted by inexperienced writers yet it is of great value to the
production process. It will help you—and perhaps more importantly your boss—to visualise the task
ahead, and it will help imposing the level of discipline the task requires. These are the steps in
producing a dummy manual:
• Take the Table of Contents you drew up earlier and use it to determine how many chapter
dividers you will need. Have one divider for each chapter and for each appendix.
• Label the dividers and put them in a ring binder.
• Put the Table of Contents in front of the first divider.
• Estimate the number of pages required for each chapter and appendix and add the appropriate
number of blank pages between the dividers. Try to be fairly precise—it will help when you come to
scheduling your work.
• Add blanks for fold-out and throw-clear illustrations in position.

• Take a moment to put together a title page and add it at the front of the binder, inside or outside.
19.3.6 Look at your source data
This part of your planning is crucial: Make a mess of it, and your manual project will be over budget
virtually before you start. The term source data refers to the entire range of input material for your
manual: specifications, design notes, schematics, wiring diagrams, brain dumps, as-built drawings, parts
lists, anything you can get your hands on and are able to verify.
Take stock of the source material that is already available. Evaluate it in terms of quality and
correctness, and make sure it is up-to-date. (Tip: it never is.)
Experienced writers evaluate each item of source data using a numerical scale that looks something like
this:
1 great stuff, use as is
2 good information, needs some rewriting (or reworking in the case of illustrations)
3 useful in places but needs total rewrite—not much better than starting from scratch
4 useless, source data needs to be generated
Estimate the work required to bring it up-to-date. Decide whether you have the expertise to do it
yourself, or whether you need help. Illustrations are treated the same as text in this assessment; if
anything it takes longer to get illustrations right.
Estimate the work required to generate any additional source data. Decide whether you have the
expertise to do it yourself, or whether you need help.
19.3.7 Plan schedule and personnel resources
Having assessed all the source data, you can work out roughly how long it will take to produce a draft
manual. You do this by taking the numbers of pages (using your dummy manual) for which you have
source data of grade 1 and multiplying it by the amount of time it takes to complete one such page.
Repeat this for the pages with source material of grades 2, 3 and 4. (You should probably write a
page or two for each grade to give you a realistic idea of how long it will take; try it for a few of
illustrations of differing quality, too.)
By now you will know how many people—writers, illustrators, reviewers, testers, editors and
proofreaders—will be involved in producing the final drafts for the manual. Knowing their availability,
you can draw up a production schedule.
19.3.8 How to get more information
Whether your interest in documentation is as a supervisor or as a writer, you’ll need certain reference
materials to supplement the information given in this chapter.
• Read a book on technical writing

• Read a book on technical illustration
• Get access to Australian Standards publications; of particular interest are:
¾ AS 1102, Graphical symbols for electrotechnology
¾ AS 1103, Diagrams, charts and tables for electrotechnology
¾ AS 1104-1978 and 1104S, Informative symbols for use on electrical and electronic equipment
¾ SAA HB8-1986, Understanding logic symbols
• Bear in mind, however, that a bunch of standards are no substitute for a good introductory text on
diagrams and schematics, and above all, on technical illustration.
• Get a dictionary. While it is one of the characteristics of good technical writing to use a limited set
of standard simple words, there are times when a dictionary is handy, and a small to medium sized
one—such as the Concise Oxford (weighing in at about 1 kg, 40,000 headwords)—will do fine.
• Get, or if you already have, consult various technical references to make sure that the world at large
shares your definitions of specific terms.
• Get a thesaurus. A thesaurus is a magnificent mind-jogger for words. Unlike a dictionary, it doesn’t
tell you the meaning of a word. Instead, it tells you a list of words that are related in some way.
• Do not reinvent book production—buy a style manual.
And, once again, study competitors’ manuals; note what you like and dislike.
19.4 Drafting the Manual

18.4.1 Assemble source data
Get the source data in as complete a state as possible.
19.4.2 Draw the illustrations
Work on your illustrations before you spend a lot of time with the text—it’s easier that way (see next
section).
Good illustrations draw attention to the concept being discussed, and they do so by the absence of
extraneous material. For this reason, technical drawings are not very suitable for use in manuals, except
for reference purposes in the appendix. You can often produce good illustrations by taking a technical
drawing and stripping away those details that have nothing to do with the current topic.
19.4.3 Draft the text round the illustrations
Once the illustrations are in place, the text often ‘writes itself’ simply by sticking to one of the basic
rules of technical writing: Reference everything that is shown in the illustrations. If you find yourself
writing about things that are irrelevant to the topic, you’ll know that they shouldn’t be in the
illustrations either.
One other thing about drafting: It may be true that some people make better writers than others, but the
quality of technical writing depends almost exclusively on whether the writer is prepared to re-write
drafts. It therefore doesn't matter much what your early attempts sound like. Just write, knowing that
you'll be coming back and re-writing it. (Taking this attitude will also help you deal with comments
from reviewers - but more about that later.)
19.4.4 How to make information understandable
Make the information complete
Complete the writing on each topic, that is, don’t forget to go back and fill the gaps you might leave in a
first draft. Keep track of what you haven’t written yet; refer back to the Table of Contents and compare
it to what you have written. If necessary, refine the Table of Contents as you go. Then complete the
information accordingly.
Make the information correct—eventually
The word eventually is important. You’re probably wasting valuable writing time if in a first draft you
start checking details. It’s better in the early stages to follow the adage Don’t let the truth stand in the
way of a good story. For one thing, frequent checking disturbs the train of thinking. When the first draft
is finished, you can check the details in one operation, or have someone do a quick unofficial review.
Thereafter, you rely on the first of the official reviewing processes to trap the technical errors. (See:
Reviewing a manual).
Give the meaning of each term
Try to be conscious of the jargon you use. As you use specialist terminology, ask whether it is justified,
or whether a ‘normal’ word would do. If you decide on jargon, ask whether the intended reader would
know the word or expression. If there is any doubt, either define the term where you first use it, or make
sure you put it in the glossary.
Put first things first
If you’re talking about a widget, ensure that the user first knows what a widget is. Don’t tell him
afterwards as an afterthought. Use “a” to introduce something the first time you mention it. Thereafter,
use “the”.
Instead of this Use this

Unscrew the widget On the left is a yellow knob, called a widget.
It is a yellow knob on the left Unscrew it.
Look at manuals for similar products
Having a look at other manuals has a two-way benefit: it gives you an idea of what to aspire to and what
to avoid. But use it as an appetiser to help your own creative juices flow, not as a feast to plagiarise. For
one thing, other people’s manuals are protected by copyright; for another, you won’t be proud of what
you produce.
How to make things easier to find
• Include a Table of Contents

• Use headings that say something definite
• Include tab dividers, and label them with descriptive names
• Include a glossary
• Include an index
• Include a chapter How to Use the Manual
• Include references to other chapters
Use simple illustrations liberally
With popular word processing applications such as

WordPerfect and Word you can create your own simple
illustrations and position them next to the text they illustrate.
This means you don’t have to number them, nor even refer to
them in text. The reader’s eyes automatically switch between
text and illustration as he unconsciously chooses his personal
method for absorbing the information.
Learn to draw schematics
Don’t gloss over this suggestion. If you think there’s nothing to schematics, you may be misled. There’s
a great difference between just drawing straight lines between boxes, and designing a schematic that
does a job. With a good schematic book, you’ll learn how to vary the thickness of lines, how to space
them, and when to bend them, all according to their importance. If you can’t find a good
book, study the schematics in the magazine ‘Electronics Australia’; the authors have been doing them
for over half a century and they’ve got the technique right.
Use terms consistently
As one of the first steps in gathering source data for a manual, create a list of standard terms. Follow the
principle: One term for each concept; one concept for each term. Hang the list over your computer
screen. Stick to it.
Use the correct terms
If you follow the previous rule, you’ll have only one term for one concept. It doesn’t matter if you don’t
like the term as long as it is unique. Then when you find a term that suits you, a few keystrokes on the
word processor will change the term globally.
Talk to the reader personally
The technical term is use the second person, which means use ‘you’. There are several reasons why you
should. One is that the reader understands you more easily. Another is that it makes it easier to write up
the instructions. A third is that it is easier for you to say something to someone you know (and if you’ve
followed the earlier rule Define your reader, you really do know him or her).
Use this instead of this

If the alarm beeps, user must press the If the alarm beeps, it is necessary to press the
Clear key within 15 seconds Clear key for silence within 15 seconds.
Use the active voice instead of the passive
The most direct, no-nonsense arrangement of a sentence is an active voice sentence with a transitive
verb like this: The man pressed the key. It is no-nonsense because it tells you about things and their
relation in a minimum of words, and it forces you to tell the whole story. The sentence: The man
pressed the key; tells you:
• who did something,

• what he did, and
• what he did it to.
The passive voice version—The key was pressed by the man—says the same thing in a roundabout
way. But the real weakness of the passive is that it doesn’t force you to tell the whole story. You could
say The key was pressed, without having to say who did the pressing. Technical language aims to be
precise and should not use such ‘language of concealment’ if it can be avoided.
Use verbs instead of nouns
Verbs are action words like make, unscrew, and dismantle create an idea of action in the mind of the
reader—a good thing if you want the reader to do something. Also, most verbs are usually easier to
understand.
Dismantle the widget Carry out the dismantling of the widget.
Use short words
Short words are usually common words, and so more likely to be understood. They are the stuff that
form everyday colloquial language, and take less time for the mind to evaluate. Use no-nonsense words
like go, get, make, and do.

The machine has stopped. The machine has ceased to function.
Go to the next step. Proceed to the ensuing operation.
Join them Perform a connection between the two
Use the concrete word instead of the abstract
If you can, replace words like many and often with actual figures. Your reader will find it easier to
grasp the meaning and will therefore take more notice of what you are saying.

Sixty per cent of the controls fail to safety Many of the controls fail to safety
How to measure understandability: the Gunning Fog Index
A Professor Gunning invented a clever way of measuring understandability. Despite its simplicity, the
Gunning Fog Index works well. It measures two attributes of a piece of text—the average quantity of
words per sentence, and the frequency of big words (those with more than two syllables). It then
calculates an index that represents the years of schooling you need to understand the text. Technical
subjects should have a Fog Index of 11 to 14; any more and you’re making it difficult for some readers.
PhD theses commonly have a Fog Index of 17 to 25 (whether they need it or not). This chapter has a
Fog Index of 12.
19.5 Reviewing the Manual

The draft manual is finished. Your baby is looking good. Polish it up a bit, get management’s approval,
and you can print it. Right?
Wrong. A baby is exactly what the manual still is. Now comes the professional part—a series of at least
three reviews that are the real means of turning the baby into a fine adult.
19.5.1 The review process
To be successful, the review process must be well-structured and planned. A number of separate
elements need to be looked at, sometimes in isolation, sometimes in combination with others.
Thirteen elements of the review
Over the entire review process, the review team will evaluate the draft manual for each of the following
thirteen elements at least once:
1 Revisions
2 Technical accuracy
3 Completeness
4 Validation
5 Terms
6 Consistency
7 Comprehension
8 Style
9 Non-technical accuracy:
10 Topic structure
11 Presentation
12 Index
13 Effectiveness test
The thirteen elements are almost mutually exclusive—but not completely. Some of them purposely
overlap, to make it easier to define what a group needs to review.
In the section Points to observe during the review, below, each of these elements is accompanied by
questions to the reviewer. The questions serve as a prompt to help the reviewer write comments on the
draft.
The stages of the review
Remember the three purposes of a manual?
• to tell the reader what they want to know,

• to tell it in a way they can understand easily, and
• to put it where they can find it easily.
During review, you divide the thirteen elements listed above among the three purposes, like this:
To tell the readers To tell it in a way they can To put it where they
what they understand easily. can find it easily.
want to know.
These elements make it These elements make it
These elements make understandable findable
it correct.
Collectively label them Collectively label them Collectively label them

A B C
1 Revisions 5 Terms 10 Topic structure

2 Technical 6 Consistency 11 Presentation
accuracy 7 Comprehension 12 Index
3 Completeness 8 Style 13 Effectiveness
4 Validation 9 Non-technical test
accuracy
The review process thus consists of three main stages, plus a final check.
• The first review (A) essentially asks: is it correct?

• The second review (B) asks: is it understandable?
• The third review (C) asks: is it accessible?
• The final review goes over the entire material again. There should be no more substantive editing,
but there may be copyediting, and there must be proofreading. The final check asks the question: is it
printable?
19.5.2 The review team—who should be on it?
Review is another word for inspection. Since modern practice sees a manual as one more product—and
sometimes the most visible product—of the company, you apply the same care in choosing the
reviewing team as you do for other quality control inspections. Each member of the team brings his or
her own knowledge to the review for one or more of the three groups of elements you want to review.
And, just as manual writers demand to be given enough time to do their job properly, so do reviewers.
A suitable reviewing team might come from these company departments:
Reviewer from this Wants to know this Reviews for attributes

department about the manual in group
1 2 3
Sales Will the customer (read • •

‘cheque signer’) be happy
with it?
Is it customer oriented?
Is it visually attractive?
Engineering Is it technically correct? • •

Does it look like a
professional product?
Documentation Does it meet the standards • • •

for documentation defined
in the company’s quality
manual?
Maintenance and • •
Service
19.5.3 Points to observe during the review
Here are the instructions to the reviewers, and the questions they have to answer for each of the thirteen
elements.
If you are a sole person reviewing a draft, you wear a different hat from when you are a member of a
panel. As a sole person, you wear your own hat and comment on how the review draft affects you—not
how it might affect another reader. But as a member of a panel you wear the hat of the intended reader,
and you discuss how that reader, rather than you, might react to the draft.
1 Revisions
Consider only those parts, which in the previous draft were marked with revisions:
• Have those parts been faithfully revised in the subsequent draft?
2 Technical accuracy
Without actually validating the procedures, read each statement in the manual:
• No wrong statement of fact?
3 Completeness
• Every illustration is referenced in text?

• Every item in text has an equivalent label on a referenced illustration (where appropriate)?
• Every label on an illustration has equivalent words in text?
• Every new item is introduced and explained once, and once only?
• Every action is described or explained in a procedure?
• Every term in the manual is defined in glossary?
4 Validation
Work through each procedure exactly as in the manual, forgetting what you already know. In other
words, put yourself in the hands of the manual and confirm that it doesn’t lead you astray. Note:
• Did you question something, which wasn’t answered immediately; close by; ever?
• Were you ever left waiting, wondering what to do?
• Was any statement in a procedure found untrue?
• Did everything happen as text and illustrations said it would?
• Any difference between an illustration and actual?
5 Terms
One thing or one event has only has only one term to describe it? (not always possible or convenient)
• A whole thing doesn’t have same name as part of that thing?

• Each term has one meaning only?
6 Consistency
This element, in particular, overlaps some of the other elements. But it is convenient to treat it as an
element in order to list the things that need to be consistent. Inconsistency refers to anything which is
expressed one way at A and differently at B. Anything means words, typefaces, typestyles, phrases,
structure, and presentation. In particular, check for:
• Terms — only defined terms used?

• Word style — similar phrases for similar events?
• Non-technical — line spaces, layout, caps, punctuation, spelling, and hyphens?
• Index — similar criteria used to decide if a word is to be indexed or not?
7 Comprehension
• Can you easily understand what is written?

• Is it written above your level of comprehension?
• Is it written below your level of comprehension?
• Any stumbles that force you to reread because something leads you in the wrong direction?
8 Style
• Paragraphs organized; terms properly introduced; flow logical?

• Are concrete words preferred to abstract?
• Are sentences simple; short?
• Is active voice preferred to passive (where appropriate)?
• No foggy words; undefined jargon?
• No overly dense sentences? Material that is too dense means that technical details are
bunched so closely that the reader can’t take them in at the normal reading rate. For example,
the sentence: Because of the interactive, conversational, rapid-response nature of timesharing,
a wide range of tasks—from simple mathematical problems to implementing complete and
complex information gathering and processing networks—can be performed could be
considered somewhat dense.
• No overpaced sentences? Overpaced means that writer assumes reader knows more than he or
she does. For example, the instruction Make a query would be overpaced if there wasn’t an
explanation elsewhere of how to make the query. Hence, the instruction Make a query (for
details see page 42) is not overpaced.
9 Non-technical accuracy
• Line spaces correct?

• Word positioning and other layout correct?
• Case correct?
• Punctuation correct?
• Spelling correct?
• Grammar correct?
• Word usage correct?
10 Topic structure
Structure is the order in which topics appear. A chapter has good structure when it deals with the topics
in the order that a reader expects.
• Are the topics in the same order as you expected?

• Does the structure give you the information you want?
• Does it give it to you when you want it? Too early? Too late?
• If you look for something, can you find it easily?
11 Presentation
This category includes such things as fonts (typefaces), type styles (bold, italic, etc), type sizes, line
spacing, page size, amount of white space, number and size of columns, positioning of illustrations, and
similar. The main purpose of good presentation is to help readers find what they are looking for. An
ordered, uncluttered, consistent presentation gives subtle navigational clues.
One measure of presentation is your first reaction when you first look at one or two pages of the
chapter, before reading the words. Do you like it? Don’t like it? Clear and clean-looking? Confusing or
jumbled? Print too big? Too small? Not enough white space? Too much? Headings catch your eye when
looking for something?
• Which presentation things do you think should be changed?

• In what way?
12 Index
First, read the index, page number by page number. Go to each page listed.
• Can you find referenced subject?

• Is it appropriate; too trite?
Second, use special printout of the manual in which hidden index text is highlighted. Read each non-
indexed phrase.
• Should it be indexed?
13 Effectiveness test (road testing)
Give the manual to someone of a similar knowledge and skill as the intended reader, but with no prior
knowledge of the equipment. If possible give it to several readers. Allow them to use the manual to train
themselves under standard conditions. As a standard test, ask them to do a procedure for which the
manual should have prepared them. Measure:
• what they misunderstood;

• what they couldn’t understand;
• what information they looked for but couldn’t find although it was in the manual;
• what information they looked for but couldn’t find because it wasn’t there.
24
Configuration of the System
24.1 Initial Concepts

Configuration of a control system is the process of converting the system software and hardware
(supplied by the vendor/vendors) into an integrated working system. Obviously, the discussion in this
chapter cannot indicate, in great detail, the precise steps required to be followed in configuring a
system. This greatly depends on the specific system that has been selected. One of the key activities of
the configuration is the creation and maintenance of the I/O database. This will be emphasised in this
chapter, as it appears to be one of the most challenging aspects on many projects. Projects tend to
rapidly grow in the number of points and the complexity of each individual analog and digital point, as
time passes.
While the focus of the workshop is on the PLC there will be a discussion on the operator interface as
this is another key component of the entire system. Typical steps in the configuration of a system are:
• training the engineers how to configure the system

• creation of the database
• creation of the PLC program logic
• configuration of the operator interface (graphical screens/ reports/ trends/ alarms)
• testing the system (using simulation techniques)
• training of the operators and maintenance personnel
• documentation of the system with engineers and operators manuals
These steps may be conducted simultaneously, depending on the particular project requirements. Apart
from training and creation of the database, all of the aspects listed above are discussed in separate
chapters toa fair degree of detail. These are:
• Creation of the PLC Program Logic (Chapters 2, 3, 5, 6 and 7)

• Configuration of the Operator Interface (Chapter 14)
• Simulation and Testing of the system (Chapter 17)
• Documentation of the system (Chapter 18)
The successful system vendor should have supplied a block diagram of the entire system. This should
show the hardware layout and addressing structures used on all the I/O racks.
416 Automation and Process Control Using Programmable Logic Controllers
24.2 Training on the system

Adequate training is critical to the success of the project. It is assumed that training will be provided by
others on the actual process and equipment (as applied to the control system itself). Typically two
levels of training should be provided:
• One is for the operators, on how to use the control system to monitor and control the process.
In addition , they should also be shown how to perform basic configuration tasks such as modifying the
screen displays for modified requirements.
• The second form of training is for the engineers and technicians on how the control system
(especially the PLC system) has been configured and the PLC and Operator Station Logic written. This
will enable them to do the modifications and enhancements to the system, should this be required by an
automation system change. In addition, detailed training on troubleshooting the hardware (especially
I/O modules) is required so that the plant technician or electrician can easily rectify any problems that
may occur.
24.3 Input/output Database Creation

This is one of the most important issues in the Control System Project, and the one around which most
configuration activities revolve. Hence it will be discussed in some detail.
24.3.1 Using Databases to Manage PLC/DCS Design Data
Every DCS or PLC project of a significant size will have thousands of pieces of information to manage.
There may be hundreds or even thousands of field devices with a corresponding number of I/O, each
with upwards of twenty discrete parameters to be specified, documented and verified. This section
discusses techniques to manage this data and thus to ensure quick and efficient configuration of the
point.
Every project will have an instrument index of some form. The instrument index is a simple list, either
being a manually maintained hard copy or an electronic database of every field device on an
installation. It provides valuable cross reference information such as instrument types, models, drawing
references, location and numerous other job specific parameters.
For those responsible for the design or maintenance of the installation's control systems the instrument
index is an invaluable aid. However, there is always additional information that must be maintained ,
that does not fit neatly into the traditional instrument index structure.
The additional data is often appended to the instrument index and any awkward parameters are covered
by a generic comments field. Usually, the instrument index is one of the first documents developed by
the project instrument engineers. It is always simpler, at the time, to add just one more field to the
index rather than develop a new document.
Complicating this approach is the use of simple spreadsheet programs (such as Lotus 123 ) to construct
the instrument index. This software is inferior to the use of a true relational database such as dBase,
Paradox, Fox Pro or Access.
On some systems, no software is used at al,l and the information required to manage the system is never
collated into a simple list form. It is only ever available from project drawings such as layouts and loop
drawings.
For smaller installations, where the total I/O count is relatively small, either of these methods may be a
workable solution. However, as the I/O count rises into the thousands, the work required to maintain
the data in a format not well suited to its use and to ensure the quality of that data, can detract from the
overall design effort.
Configuration of the System 417
The solution is to consider the entire control system’s probable total information requirements early in
the project. The word "probable" is chosen, as much of the required data will be dependant on the
direction the design takes as well as the DCS/PLC system chosen. However, it is possible (early in the
project) to put a framework in place, to manage the data. If properly designed, this framework will
allow extensions to incorporate additional parameters as required, without compromising the overall
data integrity.
Major benefits include reduced time to maintain and/or verify the data, increased quality of data and
easier automation of repetitive tasks.
This section describes such a framework developed over a number of control system design projects. It
presents a model that can be applied to most PLC (and even DCS) based stems.
24.3.2 Relational Vs Flat-File
Software to manage electronic databases can be broken into two broad categories:
• flat-file
OR
• relational
Flat-file databases are the traditional spreadsheet approach. All of the data is in an array of rows and
columns and there is a one-to-one relationship between items across each row. For example, each row
of an instrument index has details about a single instrument. The first column, or field, is usually the
instruments tag, followed by items such as instrument description, service, model, etc. As new
parameters are identified, columns are added, however, the basic one-to-one relationship is maintained.
Separate files may be kept; for example an instrument index and an I/O schedule. However, a flat-file
system does not allow any automated cross-referencing of these files, and hence automated maintenance
is at a minimum.
Popular flat-file style databases include the various spreadsheet programs available in Microsoft Works
Database and Claris Works Database.
A Relational Database Management System (RDMS), on the other hand, is designed to manage a
number of separate tables as a cohesive whole, rather than as discrete entities. A row of one table may
(or may not) relate to one or more rows of another table. A relational database can automatically track
these relationships between data, producing appropriate reports and automating much of the routine
maintenance of the system. An efficient framework, as described below, requires an RDMS.
24.3.3 Databases Specific to Control System Design
The design and construction of any control system requires management of both hardware components
and software components, and the framework models. In order to achieve this, three principle tables are
utilized. These are the instrument index, the I/O schedule and the message list (each of these may in fact
be made up of a number of individual tables. However, for the purposes of an overview, they can each
be considered to be a separate document).
The instrument index describes every separate field component that has to be purchased and/or
installed. Each record (row) of the index describes one instrument.
The I/O schedule describes the interface between the hardware and the software. Each record is an
individual input or output (analogue or digital). The actual type of I/O is not particularly significant
although one may for example maintain separate tables for hardwired I/O and those on serial
communication data links.
The message list is purely for management of software and hence its actual form is usually very system
dependant. Its purpose is to document every discrete piece of information (Process Variables, alarm
settings, engineering units, alarm groups, etc.) inside the software system, or at least available to a
supervisory system.
To highlight the differences between the three documents, consider the following arrangement.
Figure 24.1
Flow Control Loop
• Loop F-1001 is performing flow control. In the field, there is a differential pressure transmitter
across an orifice plate as well as a control valve. The transmitter produces a 4-20 mA signal and the
valve's I/P converter requires a 4-20 mA signal. The system performs PID control on the loop and
produces an alarm with an appropriate message, should the PV depart from the set point significantly.
• The instrument index will have an entry for each item, such as the orifice plate, the DP transmitter
and the control valve. It may look (in part) like the following:
INSTRUMENT DESCRIPTION LOCATION MANUFACTURER
FE-1001 Orifice Plate Main Boiler
PDT- Differential Main Boiler Rosemount

1001 Pressure Tx
FV-1001 Control Valve Main Boiler Fisher

• The I/O schedule will have an entry for each actual system input or output, in this case one for the
PDT and one for the FV. For example:
TAG NAME TYPE SIGNAL RANGE UNITS IS BARRIER
PDT-1001 A/I 4-20 mA 0-1200 kPa Y MTL-787
FV-1001 A/O 4-20 mA 100 % Y MTL-787
• The format of the message list is very system dependant, however, as an example, consider a Bailey
Infi-90 System. The message list may contain tags such as:
Notice that there is not a one-to-one relationship between the message list tag and any entry in any other
table (database). Consider a situation where there may be an alternate valve that could be used for flow
control, at the discretion of an operator. This would add another field device (one entry in the
instrument index), an output from the system (one entry in the I/O schedule) and maybe two entries in
the message list (a second flow controller and a digital switch to select a valve). In this situation the
PDT is connected in software to two discrete tags in the message list (two flow controllers) whereas the
switch is not logically associated with any particular field item or I/O.
Figure 24.2
Usage of Alternative Valve
A further enhancement could add a second flow controller (eg the two flow control valves had different
downstream pressures, requiring different PID tuning parameters) as follows:
Figure 24.3
Inclusion of a Second Flow Controller
The three tables now look something like this:
• Instrument index:
INSTRUMENT
DESCRIPTION LOCATION MANUFACTURER
FE-1001 Orifice Plate Main Boiler
PDT-1001 Differential Pressure Tx Main Boiler Rosemount
FV-1001-A Control Valve Main Boiler Fisher
FV-1001-B Control Valve Main Boiler Fisher
• I/O Schedule:
TAG NAME SIGNAL RANGE UNITS BARRIER
PDT-1001 4-20 mA 0-1200 kPa MTL-787
FV-1001-A 4-20 mA 100 % MTL-787
FV-1001-B 4-20 mA 100 % MTL-787
• Message List:
TAG NAME TYPE ZERO SPAN UNITS DEV ALARM ADDRESS
FIC-1001-A Station 0 100 m3/hr 10 1/23/3/3456

0
FIC-1001-B Station 100 m3/hr 10 1/23/3/3470
HS-1001 RCM 1/23/3/3400

There is a loose connection between the three tables (the loop number) but not a rigid one to relate each
entry of one table with a specific entry of another. Often a separate table is developed to handle the
relationships and to tie the whole package together. This will be discussed below.
24.3.4 Relationships to other Control System Documents
The complete specification of any Control System will consist of many documents other than the main
databases, and it is important that the relationships between them are very clear and that the role of each
has been be well defined. Without clear definitions of the purpose of each document, information can
easily be placed in in-appropriate places, leading to confusion and inherent contradictions within the
documents themselves.
Repeating information on many documents may often cause as many problems, as would leaving it out
completely. The effort required to maintain the information (and hence the likelihood of
inconsistencies) is increased.
For example, a common misuse of I/O Schedules, is to add comments about the function of an input.
Unfortunately when functional specifications are developed (logic drawings etc), such comments
become superfluous and are often not kept up to date.
24.3.5 Relationships to other Project Databases
Of course, on any project, there are many other areas in which databases can be applied quite apart from
the control system. These include areas such as equipment lists, document lists, cabling information,
etc.
Early in the project, consideration should be given to how the databases of the control systems relate to
other project databases, and whether any significant integration is to be put in place.
Often the responsibility to develop the various database systems on a project fall to different sections of
the design group. Also the expertise required to bring all of the parties together, and structure a single
unified system, is usually unavailable. As a result of this, each group develops its own systems in
isolation, often to discover later in the project's life that integration is extremely difficult due to some
arbitrary decisions taken early in the design.
On large projects, consideration should be given to appointing someone or some group with the
appropriate skills to work with each department in considering their information requirements and to
develop consistent data management systems. The tools available to engineers today, to manage data,
are an order of magnitude more powerful than those of only a few years ago and often the systems are
similarly more complex. If a project wide approach is to be adopted, then people skilled in the use of
modern information systems and preferably with an engineering background, should be appointed to
manage it.
The framework discussed here should allow for the integration of the control systems data with other
project databases, provided the necessary planning is done.
Potential areas of integration include:
• Cable Schedules
All I/O is cabled to devices. This can be a complex area when multi-dropped arrangements are used.
• Equipment Lists
Often filed devices are part of some larger item, or System I/O is directly connected to packaged
equipment.
• Document Lists
The instrument index usually lists many documents associated with each particular device.
Each one of these is a complex area in its own right and a complete discussion is beyond the scope of
this text.
24.3.6 The Loop Lists
As stated above the relationship between project databases are often loose and a unifying structure is
required. The Loop List provides such a structure.
While the Loop List itself is often never seen as a separate document, elements of it may appear on
some or all of the Control Systems Databases. Each entry in the Loop List defines one of the ‘Systems
Loop’ or functions. The structure of the Loop List is usually very simple, just a Loop Tag, and a
description.
For example, the Loop List entry for the example described earlier might look like this:
Loop Tag Description

F-1001 Burner Gas Fuel Flow Control
The structure of the Loop Tag, as with all the Tags above, is usually project specific. Provided the
structure is general enough to handle all databases and all configurations, the exact format is not critical.
Tables are linked together by creating a new field in each related table, to hold the Loop Tag to which
the entry is related. It is then possible for the system to associate field devices, Control System I/O and
Message List entries via the Loop Tag.
Some projects extend the Loop List by including associate equipment numbers. This then allows the
systems to relate entries in other databases to specific equipment.
24.3.7 Instrument Index

The Instrument Index documents every field device on a project. This includes devices which interface
to the Control System (transmitters, switches, etc) and also items such as orifice plates, local control
valves, etc.
Many groups will make use of the Instrument Index over the term of the project, for many different
purposes. From the ordering of instruments to the planning of maintenance procedures, the Instrument
Index is the central reference.
A typical Instrument Index may have the following fields:
• Instrument Tag Name Tags of Field Device, follows the project specific structure
• Loop Tag Name Tag of associated Loop
• Component Type Description of Device (eg Pressure Transmitter)
• Manufacturer Name of Manufacturer
• Model Model Number of Device
• Location
• Datasheet Number
• Layout Drawing
• Hookup Drawing
• P&ID
• Loop Drawing
• Comments
Many people are tempted to also include all of the Operator Interface Tags on the Instrument Index.
The justification is that they require a single document to include all project tags. This thinking is
typical of a poor understanding of Database Management Systems.
A fundamental concept of RDMS's is that the actual physical storage of data does not impose
restrictions on the reporting of that data. If Message List tags are required on the Instrument Index
report then this is easily done without actually entering the Message List tags into the Instrument Index
table.
Having said that there are unusual circumstances in which there may be justification for including tags
in both the Instrument Index and Message List. For example some projects produce datasheets for all
PID controllers and the datasheet number can be usually recorded on the Instrument Index.
24.3.8 I/O Schedule
The purpose of the I/O Schedule is to document the Hardware/Software Interface. It should detail the
electrical characteristics of each system Input & Output.
The structure of the I/O Schedule is at least partially dependant on the control system selected and the
area of responsibility of the design team.
If the full specification is to be provided by the design team, then the I/O Schedule must be a very
detailed table (or set of tables) providing explicit information about the location and route of all I/O. If
the system specifics are to be provided by others (vendors for example) then the I/O Schedule may have
less detail. However, steps should be taken to ensure the detailed information can eventually be
integrated into the I/O Schedule to assist in ongoing maintenance.
When complete (i.e. all information has been integrated from vendors, etc) the I/O Schedule should
provide all information necessary to allow rapid fault finding. This includes items such as Field Cable
Terminals, Barrier No, System Rail Terminal, System Cable, Termination Card (Row/Slot/Channel) and
I/O Card (Row/Slot/Channel).
It should also include characteristics of the signal such as signal type (Current/Voltage/Pulse),
represented range (Engineering Units) and whether the circuit is Intrinsically Safe or not.
Be careful, though, not to include fields, which rightfully belong in the Message List such as alarm
settings. Unless the I/O card itself is performing the alarming function through an inbuilt trip setting (as
is typical on many safety stems) alarms are purely a software parameter and are usually a function of the
operator interface. Other fields to be careful of include tuning parameters of PID controllers, alarm
groups and priorities, trend details and logging functions.
A typical I/O Schedule will have the following fields:
• I/O Tag Name Follows project specific structure

• Loop Tag Name Tag of associated loop
• Direction Input or Output
• Category Analog or Digital
• Type 4-20 mA, 1-5 V, Normally Open, Normally Closed, etc
• Range Range of primary device in Engineering Units
• IS Intrinsically Safe I/O
• Barrier Barrier type for Intrinsically Sage I/O
• Location Cabinet Number, Card Number, Channel Number, etc
• Comment
24.3.9 Message List
The Message List is a document that many projects will only use if they have to. The architecture of
many DCS's will require a Message List and the structure is usually imposed by the system selected.
For PLC based systems where a Message List may not be required by the system, it may be tempting to
do without one. However, this can seriously hamper the initial design effort and the ongoing
maintenance of the system.
The Message List is a formal listing of the data presented to operators, and the data available to
Management Systems. It clearly defines which parameters from the control program/configuration are
required by the Display & Management System, making it easier for both the PLC programmer and the
Display System programmer to produce their software.
As stated above, the structure of many Message Lists is imposed by the system selected. Even in cases
were a Message List is optional its structure is often highly dependant on the architecture of the system.
However, a typical Message List will have many of the following fields:
• Tag Name Software Tag. Follows project specific structure

• Loop Tag Name Tag of associated loop
• Description Text description of Tag.
• Tag Type Analog, Digital, Controller, etc
• Address Origin of Tag (which Outstation, PLC, etc)
• Engineering Units Units of Analog tags
• Range Range of Analog tags
• Alarm Settings High & Low Alarm Points
• State Descriptors Descriptions of states of Digital tags
• Alarm Groups
• Alarm Messages
• Alarm Priorities
• Comments
24.3.10 Project Reports and Deliverables
The fundamental purpose of the database system is to document the design of the project's Control
System. As a minimum, the three principle tables will be deliverables. However, the framework allows
for many other reports to be produced to assist in the design and maintenance.
24.4 General Database Design Tips

Below are a few tips to help with planning of a database. They relate specifically to Control Systems
databases. However, the principles can be applied to all database systems.
• Always plan the entire system before implementing anything. You may not know the requirements
of the I/O Schedule or the Message List when you need to create an Instrument Index but you should at
least have a rough idea of how the three main tables will interconnect.
• Your control system does not exist in isolation, neither should your databases. Consider the
information requirements of the whole project and how your data relates to that of the other project
groups.
• Breakdown your data into it's smallest discrete components. For example, if your tag number has
three sections (eg FT-1001-A) use three separate fields to store them. This allows for more flexible
sorting and reporting.
• Resist thinking of your database like a spreadsheet, they may both have rows and columns but they
behave in very different ways. Also, before adding new fields always consider whether the data would
be better stored in it's own table.
• Use your RDMS's inbuilt data integrity tools. For example, use lookup tables of valid I/O types or
maintain a table of device suppliers and models from which users of the system can pick when entering
new items.
• Be careful with 'comments' fields. Often it is useful in tables to include a field for text messages
about a record. This is okay provided the messages are regarded as 'information only'. All design data
should be in dedicated fields.
• Avoid duplication at all costs. Duplicating data can create major problems for those maintaining
your data. It should never be necessary to enter the same information into your system more than once.
If you find you need to do this, reconsider the structure of the databases.
A powerful technique for reducing redundancy in a database system is called normalisation. It involves
breaking down data into record groups for efficient processing. Most general texts on database design
will cover normalising and while it may not be necessary to go through the formal normalisation
procedure for each database system you build, an understanding of the principles will help you design
more efficient systems.
3
HMI (Human Machine Interfaces)
In this chapter, you will learn:
• Introduction to HMI station

• Control room ergonomic issues
• Design considerations of HMI
• Components of HMI station
• Hardware and software interface of HMI
3.1 Introduction
When we talk about the word ‘HMI’, an Operator station (through which a human can interact
effectively and efficiently with machine or process) comes to mind.
That’s why it is called ‘Human Machine Interface’.
Need of HMI
• Process visualization.
• Gives security in the production.
• Provides data integrity.
• Can be used for controlling via PLC.
• Improves quality of the product.
• Helps to reduce costs.
What are the different capabilities that it offers?
¾ Online status of machine or process conditions (i.e. feedback) through dynamic graphic screens.
¾ Online On/Off commands can be issued for valves, actuators, motors, etc.
¾ Online changes in set point of process control loop can be done.
¾ Informing any process abnormalities instantly to operator through alarms screen.
¾ Archiving of different process parameter values for record and analysis through history display.
¾ Automatic generation of reports related with process.
Many more features, other than those just mentioned, are available, making it one of the most
important components of any SCADA system.
370 Practical SCADA Systems for Industry
There are many HMI hardware/software packages in the market.
Figure 3.1 shows the basic role of a HMI station.
Figure 3.1
Basic role of HMI
As can be seen, the HMI is acting as the interface between an operator and the actual process. It
provides the operator with a graphical display of the process parameters, enabling him to interact
with the process by sitting at one place.
Depending on the functional requirements and volume of process, one could have multiple HMI
screens/terminals per operator. In large systems each operator may only control part of the process
due to the workload.
The HMI can be broadly classified in two main categories:
1. PC-based HMI station

2. Graphic operator displays
1) PC-based HMI station:

The HMI station is installed on a computer (generally industrial grade) using HMI software
package. This HMI station has a PC monitor (normal or touch screen), keyboard and mouse.
Some vendors supply special types of keyboards and other components depending on the
requirement. Typical PC-based HMI station often looks just like a normal common computer
station.
2) Graphic operator displays:
These operator displays are generally small graphic display units with onboard special function
keys, as well as regular keys and a communication port.
They are basically used for providing the operator access to machine applications or small process
control units.
HMI 371
Figure 3.2
Typical operator panel (Courtesy: SIEMENS)
The unit can be programmed as per the process requirement and thereafter used for monitoring and
controlling process. When one takes a look at features offered by it, then it becomes apparent that
the HMI offers comparatively less features to that of a PC-based HMI station. Apart from an array
of features, the basic functionality offered by both of these systems remains the same.
Now, we need to review the ergonomics for the Control Room. This encompasses:
• Environmental considerations
• Control room layout.
• Lighting, sound, ventilation and colours.
3.2 Control Room Ergonomics
3.2.1 Environmental Considerations

The environment in which the system is installed must be appropriate to the computer system and
the associated electronics systems. Typical environmental conditions that are considered suitable
for the standard and the industrial environment are listed in Table 3.1. Obviously the environment
in a control room should not have these extremes; but the equipment should be rated for these
ranges. Typical control room environmental ranges are discussed under ergonomic requirements.
Industrial computer systems may be mounted in a less stringent environment than for the standard
air conditioned control room.
Table 3.1
Environmental Conditions
ENVIRONMENTAL RECOMMENDED RANGE

CONDITION
INDUSTRIAL STANDARD
Operating Temperature 0 "C to 60"C 0"C to 50"C
Storage Temperature -40"C to 85"C -10"C to 60"C
Relative Humidity 5 to 95% RH 5 to 90% RH

Should the operational personnel believe that there could be problems with the environment having
excessive dust, corrosive vapours, moisture or oil the best approach is to mount the computer
system in an enclosure. This will provide the necessary protection for the processor. Special
consideration may have to be given to such issues as vibration and it may be necessary to mount the
computer in the enclosure on shock mountings to absorb some of the vibration. Ensure that the
enclosure doors can be easily opened and that the heat is allowed to dissipate. Note that hot air rises
and there can be build up of heat at the top of the enclosure and a fan may be needed to circulate the
air. In general, place less heat sensitive and heat generating devices, such as transformers, circuit
breakers and DC power supplies above the PLC processor and I/O racks. Computer manufacturers
have tables available providing data on the allowable ambient temperatures around their equipment.
Generally computers do not immediately fail when the heat is excessive but have intermittent drop
outs and may suffer long term damage.
The enclosure should be large enough to allow space to work on the system and to observe
diagnostic lights/LED's etc.
3.2.2 Typical control Room Layout
A typical layout is given Figure 3.3.
Figure 3.3
Typical Layout of the Computer Control Room
The horseshoe control room layout is designed so that anyone in the centre can see all the screens.
Operators at any of the operator displays should be able to view the entire control room's screens
without undue difficulty as well.
HMI 373
Although the focus in a control room is normally on the equipment and computers, the amount of
space for the operators should also be maximised to avoid congestion (particularly when there is a
change over of shifts). Operators will spend a considerable amount of time in from of their
consoles and the layout should ensure that the operator can see anyone coming into the control
room and not have people peering over their shoulders.
Similar areas in the system that are being monitored should be situated close together to avoid
unnecessary movement by the operators to see what is going on.
The voice communications system (either radio or telephone) should be situated as close as possible
to the operators and for other persons entering the control room. For the control room indicated in
the diagram at least three internal telephones should be provided for easy access (with frequently
used numbers programmed into the system).
The amount of desk space should not be compromised. Space should be allowed for manuals and
other items to be left on the desk without unnecessary clutter.
The printers for the system are situated in a separate room to isolate the operators from the
associated (rather repetitive) noise. The associated inconvenience of having to walk to the printer
room to view alarms can be minimised by providing on-screen alarm reports.
A separate meeting room should be provided to avoid holding meetings in the control room which
are of no interest to the operator but which disrupt his work.
The following specific issues should also be considered in the design of the computer control room.
3.2.3 Lighting
Tungsten Halogen light sources produces warm lighting while the light life of 2000 to 4000 hours is
reasonable. They are also not diffused and can produce significant shadowing. If longer life is
required tubular fluorescent lamps have a life of 5000 to 10000 hours but may have variable colour
rendering and variable apparent colour if the correct colour tube is not chosen.
The luminaries should be fixed overhead and provide direct lighting. Desk lighting can be installed
to provide localised lighting over the keyboard.
A general level of lighting of 400 lux is recommended throughout the control room with a personal
level of 200 to 600 lux set by the operator.
An average reflectance level of 30 to 60% is recommended for the walls. The ceiling should have a
reflectance of at least 75% with floors an average of 40%.
3.2.4 Sound Environment

A maximum noise level of 54 to 59 dB(A) is recommended.
3.2.5 Ventilation
The air temperature should be between 20"C and 26 "C with relative humidity range of 40 to 60%
RH Fresh air should flow at the rate of 7 litres/sec per person throughout the control room.
2
SCADA Alarm Management
2.1 Objectives
In this chapter, you will learn about:
• The key features of effective alarm systems
• Alarm design process
• Prioritization of alarms
• Alarm display options
• Alarm processing
• Alarm list displays
• Filtering alarms
• Alarm reviews
• OPC Alarm and Events clients and servers
2.2 Introduction
Alarm systems are an integral part of the human-machine interface. An alarm system consists of
both hardware and software including—field signal sensors, transmitters, alarm generators and
handlers, alarm processors, alarm displays, annunciator window panels, alarm recorders and
printers.
Alarm systems, whether hardwired or software configured, play an important role in monitoring and
controlling industrial plants and equipment and are an integral part of the control system. Alarm
systems indicate the abnormal conditions and problems of the plant and equipment to the operators,
enabling them to take corrective action and bring the plant/equipment back to normal conditions.
Alarm systems give signals to the operators in the form of audible sound, visual indications in
different colors and/or continuous or blinking, text messages, etc.
An alarm system needs to bring the following to the notice of the operator:
• Problems that need operator attention
• Process changes that require corrective action
• Unsafe operating conditions before emergency shut-down of plant
• Hazardous conditions
• Deviations from desired/normal conditions
An alarm system also assists an operator in:

• Maintaining the plant, equipment and processes within normal and safe operating
conditions
• Correcting dangerous and hazardous conditions that arise in the plant before emergency
shut down is initiated by the emergency shown system. This results in increased
plant/equipment safety and also improves plant/equipment availability.
• Recognizing a hazard well in advance and to take corrective action to avoid hazards.
• Better understanding complex processes and plant conditions and to identify deviations
from desired normal operating conditions.
2.3 Effective alarm systems

For designing an effective alarm system, it is important to consider the following key points:
2.3.1 Present only relevant and useful alarms to the operator
An effective alarm system presents only the alarms that help an operator in monitoring and
controlling the plant/equipment rather than being a nuisance or hindrance. The operator’s time and
attention should not be diverted by alarms which do not require any response or intervention from
the operator and can be ignored. Otherwise there is a possibility of the ‘Cry wolf’ effect and the
operators may lapse into a frame of mind that the alarms can be ignored.
When designing an effective alarm system, it is important that every alarm that is configured and
presented to an operator should be useful and relevant to the operator. This means that a change in
the condition of the plant/equipment, which requires maintenance personnel to take corrective or
preventive action but is not relevant to an operator running the plant, should not be presented as an
alarm, but sent directly to maintenance staff.
Example 1
In a cement plant with a 1000 kW H.T. motor for a vertical roller grinding mill, it is important to
monitor the motor bearing and winding temperatures. The temperatures of both the drive-end & the
non-drive end bearings and of six winding temperatures of the H.T are measured and the following
alarms are set:
For each bearing:

• High alarm at 80°C (alarm to alert the electrician to check the bearing)
• High high alarm at 100°C (to trip the H.T. motor)
• For each winding:
• High alarm at 80°C (Alarm to alert the electrician to check the winding)
• High high alarm at 100°C (to trip the H.T. motor)
Here the alarms configured for the H.T. motor bearings and windings temperatures are relevant for
the electricians who have to monitor and maintain the H.T.motor. The plant operator will be more
interested in the alarms related to the vertical roller grinding mill processing such as feed rate, mill
outlet material temperature, mill outlet draft, etc. which are relevant to him for operating the mill at
optimum levels.
2.3.2 Each alarm should have a defined response from the operator
For an alarm system to be effective, every alarm should have a defined response from an operator.
The response should be in the form of a preventive and/or corrective action or an acknowledgement.
At times the response to an alarm can be conditional. Some alarms like ‘plant start-up sequence
completed’ or ‘equipment stopped/tripped’ inform the operator to change his response—how he is
monitoring or paying attention to the plant/equipment. There may not be any immediate action
required but a purely mental response from an operator is important to make such cognitive change.
SCADA Alarm Management 349
It is important that every alarm should have some response that is clearly identified and defined
during the design stage. If a response for every alarm is identified and defined during the design
stage, it helps in formulating alarm response procedures and training operators. If a response to an
alarm cannot be defined or identified, such signal should not be configured or presented as an
alarm. Such signals, which provide only event information or signal state change, will get confused
with the alarms, which require an operator to pay attention and respond. There are many events,
which occur in a plant but are only informative in nature; these events should not be configured and
reported as alarms. However, such events should be recorded separately as event history and
presented in events list displays.
2.3.3 Allow adequate time for an operator to respond to an alarm
As discussed previously, the operator is expected to respond to every alarm. It is essential to allow
adequate time to an operator to respond to an alarm, so the alarm should be given in advance,
allowing enough time to take corrective action to rectify the problem or fault. In addition, the rate of
the alarms should not exceed the capability of the operator to respond to these alarms. It should also
be remembered that the operator’s functions include many other activities and responsibilities apart
from responding to and handling alarms. As the time required for other activities imposes
constraints on alarm handling workload, the process control system for the plant, plant-sections,
HMI and the alarm system should be designed as such that the overall functions of an operator are
manageable.
An average workload (W) imposed on an operator by the alarm system is determined as follows:
W=RT
where;
R – is average rate of alarms presented
T – is average time taken to respond to the alarm
While designing an alarm system, human limitations and ergonomic factors must be taken into
account to make the alarms system effective.
Example 2: Manageable alarms
In a plant, a SCADA alarm management system presents alarms to the operator at an average rate of
1 alarm per 120 seconds. To respond to each alarm takes the plant operator an average of 40
seconds.
The average workload (W) imposed on the operator by DCS alarm management system is:
W = (1 / 120) x (40) = 40 / 120 = 0.333 = 33.3 %
This means on an average the plant operator has to devote a 1/3rd of his time attending and
responding to the alarms presented by the alarm management system.
Example 3: Over-loaded alarms

In another plant, a mimic panel with indication lamps and an alarm annunciator panel based alarm
system presents alarms to the operator at an average rate of 1 alarm per 40 seconds. The plant
operator takes an average 30 seconds to respond to each alarm. In this case the average workload
(W) on the operator imposed by the alarm system is:
W = (1 / 40) x (30) = 30 / 40 = 0.75 = 75 %

In this plant, 75% of the operator’s time is consumed by the alarm system. The operator is
overloaded with alarms.
2.3.4 Configure and present only a good alarm
• To design an effective alarm system, it is equally important that only a good alarm is
configured and presented as an alarm to an operator. Some of the characteristics of a
good alarm are as follows:
• It must be relevant and not a spurious alarm
• It must be presented in time. Neither in advance before the operator response is needed
nor too late leaving no time for the operator to respond or take corrective action.
• It must draw the attention of the operator towards important problems.
• It must clearly identify the problem and indicate the action (s) to be taken.
• It must be understandable. The alarm message should be clear and easy to understand.
• It must indicate the priority of the problem.
• It must be unique. Not a duplication of another alarm creating increased alarms load on
an operator.
One weakness in many systems is the occurrence of trivial alarms, which may irritate and confuse
the operator. Typical trivial alarms are summarized in Table 2.1.
TYPE OF SYMPTOM REMEDY

ALARM
Consequential Repetitive alarms caused by a condition Inhibit the alarm until the condition
that the operator is aware of. is remedied.
Out of service Alarms are caused by equipment not in Inhibit the alarms
service
No action alarms Operator unable to rectify the problem Delete the alarm from the system
Equipment Regular equipment maintenance etc causes Ensure the alarms are suppressed for
changes alarms this period by added alarm logic.
Minor event Operator constantly being notified about Delete alarm and replace with event
trivial events. recording.
Multiple Many alarms triggered by one fault. Use first up alarming to reduce the
alarm information.
Cycling Signal close to alarm level moves the Expand the range of signal before
alarm in and out of alarm condition. moving into alarm.
Instrument drift Drift of instrument causes alarm Ensure there is tight control on the
calibration of instruments.
Table 2.1
Typical trivial alarms
2.4 Alarm Design Process

Designing an alarm system is a process. While designing each alarm it is important to consider how
important the alarm is and what its reliability should be. To determine the importance and reliability
of an alarm, it is necessary to carry out qualitative and quantitative risk assessment to consider
whether the alarm is safety related and whether it is to be implemented on an independent stand-
alone system as opposed to the process control system. Safety related alarms should be given
special considerations while designing the HMI. The design of an effective HMI for a plant is a
complex task and involves a variety of human related issues and ergonomic factors. Designing an
alarm system also involves many design activities at different stages.
2.4.1 Assessment of risk

• Assess risk to identify alarms to protect against economic, environmental or safety
risks.
• Develop safety plan for the plant
• Identify the safety function of the operator
• Identify and review alarms that provide significant risk reduction
2.4.2 Ergonomic factors

• Identify the functions of the operators and the number of operators required in the plant.
• Design of operator interface–Number of terminals, HMI, graphic/mimic displays, color-
coding, etc.
• Design of alarm system–Alarm displays, alarm annunciation – audio-visual, etc.
2.4.3 Design alarms

• Prepare data form for each alarm
• Review proposed alarms not deriving from risks assessments
• Identify alarms with special integrity or special display requirements
• Prepare response procedures for alarms
• Design and selection of alarm sensors
• Design hardware for conditioning of alarm signals
• Installation of alarm sensors and signal conditioning transmitters
2.4.4 Integration
• Rationalize proposed alarms list
• Review the alarm system and ensure it meets the key design principles
• Identify alarm processor
2.4.5 Configuration of alarm system

• Install the alarm system hardware
• Configure hardware and/or software for the alarm system
• Prepare database of alarms
• Install and configure hardware and/or software for each alarm
• Configure combinatorial logic for alarms.
2.4.6 Testing and commissioning of alarm system

• Test all the facilities of the alarm system
• Test alarm signal sensors and transmitters
• Test hardware and/or software configurations of each alarm
• Evaluate overall acceptability of the alarm system from ergonomic point of view.
• Measure the performance of the alarm system.
• dentify testing requirements
2.5 Prioritization of alarms

A good alarm system has all the alarms assigned a priority so that the important alarms at any point
of time are evident to the operator. Priorities assigned to alarms help the operator to decide which
alarms to deal with first when there are several concurrent alarms. Prioritization of alarms is
essential during high alarm activity when the operator has to structure his response so that the
response to critical and important alarms is given first priority. Prioritization of alarms also helps
the operator during low alarm activity by bringing to his attention the important alarms that need
urgent intervention.
Priorities are assigned to the alarms based on the following two factors:
• The severity of the consequences in terms of safety, environmental and economic issues
that the operator can prevent by taking the corrective action(s) in response to the alarm,
and
• The time available, compared with the time required for taking the corrective action and
to get the desired result.
Both the severity of consequences and the time available depend on the condition of the plant and
these factors should be recognized by the prioritization. It is desirable to have a dynamic
prioritization system for alarms that automatically ranks the alarms based on the severity of
consequences, the time available and the changing condition of the plant.
However, in practice a simple way of putting alarms in a few priority bands is followed by the
manufacturers of alarm processors for the sake of simplicity. The priority is used to change the
conspicuity of the alarm as displayed and the stridency of the audible warning. Ergonomically, use
of three priority bands in one type of alarm display is quite effective for presentation of alarms.
Depending on the needs of a plant, there can be more than one alarm system. However, it is
recommended that the definition of alarm priority should be consistent across the systems and in
totality there should not be more than four normal priority bands.
In a plant, alarms may be configured and implemented within the process control system and/or a
standalone hardwired alarm system. Various types of alarm systems are:
• Configured within a process control system,

• A standalone alarm system, and
• A combination of a standalone alarm system and an alarm system within a process
control system.
Figure 2.1 shows three bands of alarm priorities–‘high’, ‘medium’ and ‘low’. If all alarms are
configured and implemented in the process control system, then it must be ensured that there is no
safety related alarm configured unless the control system itself is safety related.
If a standalone alarm system is used for configuring and implementing all the alarms, then the high
priority alarms include the safety-related alarms. However, if a combination of a standalone alarm
system and alarm system configured within the process control system is used, there is a possibility
of overlapping priority bands of alarms between the two systems. As shown in Figure 2.1, there are
two bands of alarm priorities, ‘high’ and ‘critical’, in the standalone alarm system. The critical
alarms may include safety related alarms and the alarms related to critical economic risks and
significant environmental risks, whereas alarms in the process control system are configured in
three alarm bands–‘high’, ‘medium’ and ‘low’. The alarms related to process and plant/equipment
are configured in the control system in these priority bands, depending on the intervention or
response required from the operator. It is important to note that the ‘low’ priority band alarms
should not be seen as useless alarms and must not be ignored by the operator.
Figure 2.1
Alarm priority bands
(i) Critical alarms: Critical alarms are in the higher priority band. Critical alarms include the safety-
related alarms that would have to be implemented to have at least a safety integrity level SIL 1.
Other alarms having significant economic and environmental risks may also be included in the
higher priority band provided these do not create any confusion. While designing, these alarms may
be implemented with the same integrity level as the safety related alarms resulting in ergonomic
benefits and reliability. Apart from having three priority bands in an alarm system, the following
flexibilities can be used while designing the alarm system:
(ii) Additional priority bands: In order to simplify the operator interface, flexibility of assigning
additional priority bands for signals that are normally not displayed but the operator may like to
have a look on these using alarm lists or standard displays. Such signals may include alarms that
have been logically suppressed, control loop status changes, etc. but care must be taken so that the
requirement of each and every alarm having a defined response is not undermined. At times, it is
useful to display logically suppressed alarms suitable coded on schematic displays.
(iii) Sub-division of priority bands: At times it may be desirable to sub-divide the priority bands. If
sub-division of priority bands is done at all, it must be done with great care to avoid confusion
between sub-divided priority bands. For example, fire and explosion alarms for a pulverized coal
hopper can be categorized as critical safety related alarms and displayed separately from the other
critical alarms and may also have a separate industrial hooter/siren as audible warning.
(iv) Priority of alarm changes with time: The priority of an individual alarm should not necessarily
remain fixed for all time. If possible, it is useful to change the priority of an alarm depending on the
plant conditions to make the alarm system more effective.
(v) Setting alarm priority: The priority of an alarm depends on the severity of the economic
consequence and the time available.
(vi) Managing priority: For a good alarm system it is imperative to have written rules on
assignment of priorities to the alarms. These rules should be consistent for all the alarms in all the
alarm systems whether within a process control system and/or standalone alarm systems.
Alarm Priorities
As a rule of thumb, only four alarm priorities should be implemented. These are:
1. High Priority
Alarms that give warning of dangerous conditions that could cause a shutdown of a major activity.
2.Medium Priority
Alarms that should be acted on as quickly as possible; but will not cause a shutdown.
3.Low Priority
Alarms that should be dealt with when time permits.
4. Event Only
Information related to statistical or technical issues. No annunciation sounds are required for these.
The limiting of the number of types of alarms is in order to keep the system straightforward and
ensure easy interpretation of all of the alarms.
2.6 Alarm display options

Alarms are either displayed on a Visual Display Unit screen in the form of alarm lists or graphical
display schematics or on separate annuciator panels consisting of a separate light window for each
alarm.
2.6.1 Alarm lists
In SCADA based alarm systems, alarm list displays are the most common way of displaying the
alarms. An alarm list provides display of different alarms within a single window. However alarm
list displays should be designed such that the repeating alarms are kept to a minimum and the alarm
lists are useful for the operator.
2.6.2 Graphical display schematics
Another way of displaying alarms on SCADA systems is to display alarms on graphical display
schematics; though, in practice it may not be possible to display every alarm on the schematics.
Only critical alarms or general plant status related alarms should be displayed on schematics.
Another option could be to have a small window on the schematic for displaying the most recent 3
or 5 alarms.
2.6.3 Annunciator displays
Alarm annunciator displays consist of arrays of annunciator windows. Annunciator displays provide
immediate access to information and excellent spatial pattern recognition. The annunciator displays
are easily visible and easy to use. However, they do not provide detailed and additional associated
information about the alarm and are not suitable for potentially large number of alarms. With more
usage of SCADA systems, use of annunciator displays has become less common. But these are still
useful for standalone dedicated alarms particularly safety related critical alarms.
2.6.3 Audible alarm warnings
Audible warnings with an industrial hooter, electronic buzzer or beeps are generated in conjunction
with the occurrence of alarms requiring immediate operator attention (as shown in Figure 2.2).
Different level/pitch of sounds that can be easily discriminated by the operator should be used so
that the operator can identify the priority of alarms. The audible warnings should be set at levels
higher than ambient noise. At the same time it must be ensured that the sound warning is not painful
and distracting to the operators. Audible warnings should be easily recognizable by varying the
pulse length and repetition rate of pulses or groups of pulses. The same pattern of audible warning
should be used only for one type of function.
In general, it is recommended that higher priority alarms are louder, lower pitched and having
higher pulse repetition rate than the lower priority alarms. If different priority alarms occur at the
same time, only the audible warning for the highest priority alarm should be activated.
Figure 2.2
Activities within an alarm system on occurrence of an alarm
2.7 Alarm processing

In order to generate useful and meaningful alarms, it is required to process the signals received from
the alarm sensors before the alarm is displayed to the operator. Logical processing techniques are
also useful in improving the operational value of the alarms. However, logical processing of alarms
should be done with great care and possibilities of errors should be minimized. The operators must
be kept informed and updated about the changes made by logical processing of alarms such as
automatic suppression, etc. For a safety related alarm, any logical processing should be in
compliance with the requirement of safety regulations adopted for the plant.
2.7.1 Grouped alarm
A single alarm may be used for display to represent a number of different events related to
plant/equipment. Grouping of alarms is useful and valid only when all the grouped alarms have the
same priority and require the same initial response from the operator. Use of grouped alarms does
not reduce the total number of alarms that are annunciated to the operator. It is always a good
practice to design grouped alarms in such a way that they are re-displayed and need re-acceptance
by the operator if another initiating event reoccurs while the grouped alarm is already standing.
Example:
An air compressor may have three alarms–Cooling water flow low, cooling water temperature high
and compressor motor trip grouped as a single alarm –air compressor faults. Whenever the alarm
‘air compressor faults’ occur, the operator informs the compressor attendant/operator to investigate
the problem related to the compressor. The attendant goes to the compressor-room and investigates
the problems based on local information whether the cooling water flow is low, or cooling water
temperature is high or the compressor motor had tripped. In the case of grouped alarms, the
operator will require more information about the specific fault or problems that caused the grouped
alarm to occur. As seen in the above example, the operator will require an investigation of the
fault/problem by another operator or equipment attendant, which can be time consuming. However,
in DCS/SCADA based alarms system signals used for generating grouped alarms are generally used
to generate separate alarms. However, grouping of alarms can be effective in cases where there is
redundant instrument, which generates multiple alarms.
Grouped alarms are used to highlight the alarm related equipment/plant area in the plant overview
schematic or the flash LED/light of the plant area schematic selection buttons.
2.7.2 Alarm suppression
Various alarm suppression techniques are used for assessing the alarm signals whether they are
appropriate for display to the operator or not. Alarm suppression techniques should be applied with
great care as often safety related problems arise due to inappropriate application of suppression
techniques on safety related alarms. Suppression techniques can be used for reducing the alarm
priority rather than eliminating the alarm.
Some of the alarm suppression techniques are:
1. Redundancy logic: Often more than one measurement is made for a process variable and used for
majority voting in safety systems. If alarms are generated from each of these measurements then
there will be multiple alarms generated indicating the same event/fault. In such a situation,
suppression logic is used to ensure that only a single alarm is displayed to the operator. Sometimes,
even the same alarms are generated by different alarms systems. It may be useful to suppress such
duplicate alarms without compromising on the integrity of the alarm.
2. Eclipsing: At times there are several alarms generated from a single process variable. Such as–
Water tank level low alarm and another water level low low alarm at a slightly lower setting.
Suitable logic can be used to suppress alarms with lower significance when more significant alarm
has been raised. In the case of a water tank, level low alarm may be suppressed when level low low
alarm is raised. Eclipsing may results in less numbers of the alarms displayed to the operator but it
may not always result in less numbers of alarms that operator has to accept.
3. Plant/Equipment out-of-service: Some of the alarms are relevant only when the plant/equipment
is in operation. For example, when an air compressor in the plant is stopped for preventive
maintenance, the compressed air pressure low alarm has no relevance. Such alarms, which may not
be relevant when the plant/equipment is out of service, may be suppressed using a suitable logic.
Sometimes, the priority of such alarms is reduced for just logging the event in the Journal and the
alarm is not displayed to the operator. The operator should be provided with a list of suppressed
alarms and he should be able to override suppression, if required.
4. Operating mode: As discussed earlier, some alarms are relevant during a particular mode of
operation of the plant. If there are a lot of irrelevant alarms generated during a particular mode of
the plant operation, it may be required to suppress alarms or make some changes to alarms settings
during the particular operating mode of the plant. For example during a cement plant start-up it may
be difficult to control dust emission levels from the Chimney than when the plant is running stable.
Following are some typical modes used for suppressions of such alarms, however the modes and
alarms suppresses may differ from plant to plant:
(i) Plant start-up
(ii) Plant operations stable
(iii) Plant shut-down
(iv) Plant under maintenance
(v) Different stages or different recipes in Batch processes
At times, the transition between the various modes is not clearly defined and changes from time to
time. Also at times, different alarms may be relevant at different stages in the transition and may
depend on the direction of the transition. Hence, the suppression logic must be designed with
utmost care. It is good to carry out logical processing for suppression based on identification of
mode and inform the operator about the mode change and seek his/her confirmation.
5. Major plant disturbance/upset: After a major plant disturbance/upset, the operator is overloaded
with alarms. Major plant disturbances or upsets are relatively hazardous periods of plant operations
and pose a lot of stress on the operator. It is quite important that the effectiveness and performance
of the alarms is improved for this period. This can be done during the priority allocation or alarm
improvement program. Many alarms that occur after a major plant disturbance/upset are related to
event that is expected to occur. During a plant shut down, tripping of many interrelated plant
equipment is expected and many process parameters will go beyond their normal operating ranges.
Therefore, a suitable logic for suppression of such expected alarms can provide a significant
reduction in load of expected alarms having less operational value for the operator.
2.7.3 Intelligent fault detection
Most of the alarm systems are configured as one input signal to generate one alarm output. However
with logical processing of alarms-intelligent fault detection can be achieved to reduce the amount of
information displayed and at the same time increases its effectiveness and usefulness. In complex
systems, several alarms are generated following a fault and complex alarm processing systems are
used to identify the root cause of the fault based on the pattern of the alarms generated. Following
are some of the techniques used for intelligent fault detection:
Pattern recognition: To address the problem of alarm overload or excessive alarms during a short
period of time, computer based analysis of alarms and finding correlation between logical cause of
the alarm and its consequences are required. Identifying a standard pattern of alarms is another way
of addressing the problem. A pattern of alarms could be identified for particular faults related to
plant equipment or the complete system.
Though the pattern recognition technique looks quite attractive, in practice such pattern recognition
techniques have limitations as listed below:
• In large plants there are a large number of faults, making storage of patterns and
comparison a cumbersome exercise.
• The number of faults that can be reliably analyzed before they have occurred is limited.
• Combinations of faults are not easily catered for.
• Creating and maintaining such an alarm analysis systems are resource intensive.
• Many such alarm analysis systems have failed to demonstrate the ability of reliably
identifying the root-cause of the fault.
• In practice, due to the above constraints, the pattern recognition technique for alarm
analysis has limited applications in complex and large plant/equipment.
However, it can be useful for some restricted applications.
Neural network techniques: Until recently, alarm analysis systems used computer based patterns
and relationships that required a lot of dependence on computer coding. Currently, neural networks
techniques are being used. Such programs mimic the operations of human brains for analysis and
help in plant fault analysis without any logic modeling or pre-defined rules. A neural network
consists of a large number of interconnected nodes. Each node takes a scalar value of the signal fed
through the interconnections. Output signal for each node is derived based on the combination of
the node values. The neural network is presented in data information of parameters representing the
plant state. For each set of data presented, the network identifies the relationship between input
signals and the resulting output signal. The neural network makes a reliable set of rules based on
data presented for normal plant operations and major plant faults. These techniques have been used
in research studies and are yet to be applied in full-fledged working alarm system applications in
industries.
Knowledge based reasoning: With the advent of efficient symbolic processing, object oriented
programming techniques and powerful computing platforms have made it possible to detect faults in
a better and efficient way. In knowledge based reasoning, plant behavior is modeled in symbolic
logic form. The plant knowledge is programmed in high level programming language similar to text
in English.
Example:
Let us consider the example of a bearing lubrication system. A typical logic for knowledge-based
reasoning may be as follows:
IF (Pump-1 is ON) AND (Lub Oil Flow to Inlet Bearing Low)
THEN Give a message “Pump-1 has fault, Start standby Pump-2”
Fuzzy logic: Fuzzy logic is used for intelligent fault detection in the large automated plants. The
most common use of fuzzy logic based system is for Rotary kilns in the cement plants. For
intelligent fault detection, assigning probability of occurrence to the each specified condition
extends pattern recognition technique further. The present alarm state is then used to estimate the
probability that is then compared with the stored pattern values. Though fuzzy logic based expert
system are in use in industrial applications, it has been used in very limited applications of
intelligent alarm systems.
Model based reasoning: Another technique for fault detection in large complex plants is
mathematical model-based reasoning. In this technique differential equations that describe the
behavior of all the relevant plant parameters are run on a real-time computer. The model generates a
set of data that describes the instantaneous value of various plant parameters at various nodes in the
process. The data generated is again compared in real time with the actual plant measurements.
Faults in the plant are reflected by the measured values of the plant parameters. The difference
between the modeled parameters and the measured plant parameters is detected, and suitable logic
in the computer is applied to identify the various faults in the plant well in advance to the
conventional alarms detecting them. All the above intelligent fault detection techniques discussed
derive the higher order intelligence about the plant from lower order information like process
signals/measurements, alarms, event information, etc. These techniques complement existing basic
process alarm systems. Results of these techniques are reliable only if the basic information system
is reliable. These approaches should not be seen as a cure or substitute for basic alarm systems.
2.7.4 Automatic alarm load shedding

As discussed earlier, human beings have limited processing power. There are fundamental
limitations on the amount of information that a human operator can assimilate and corrective
actions that can be performed by him. A plant operator has only a small proportion of time available
for processing of alarms and responding to them. In large systems, there can be major
disturbances/upsets resulting in many alarms within a short period of time. There is always a
potential for alarm load exceeding the operator capability to handle and respond to alarms. Such
risks even exist for the plants having well design alarm systems with all spurious alarms eliminated.
There are always possibilities, that the useful alarms may be generated but the operator may miss
them or fail in responding to the alarms. When the operator is overloaded with alarms, to cope with
the plant situation he will accept alarms without reading them or may look only at selective alarms
having critical or high priority on plant overview display. Alarm overloads are associated with
operator stress. So automatically limiting the alarm display rate at the rate at which the operator can
easily handle would result in considerable benefits. To achieve this most appropriate operational
alarms are selected and displayed for the operator.
2.8 Design of alarm list displays

In practice, though, there are many different ways of displaying alarm lists. We will discuss design
features for alarm list displays, which are most commonly used in SCADA systems.
2.8.1 Alarm state
In designing alarm list displays, it is necessary to define terminology for the different states of the
alarm to be displayed in the alarm list. Various alarm states are:
• An alarm is in a raised state or initiated when the condition for generating the alarm has
occurred. The alarm is said to be in a standing state while the condition that generated
alarm persists. The terms ‘raised state of the alarm’ and ‘standing state of an alarm’
are often used interchangeably.
• An alarm is cleared when the condition in which the alarm was generated has returned
to normal.
• An alarm is accepted when the operator acknowledges the alarm by a mouse click or
push button. Until the operator acknowledges an alarm, it remains in unaccepted state.
• An alarm is reset when it is in a state in which it can be removed from the alarm display
list.
A flow chart of various states of an alarm and operator actions that cause transition between these
states is shown in Figure 2.3.
Figure 2.3
Flow chart of various states of alarms and action causing transitions
2.8.2 Alarm Indication

Each alarm on the alarm list display should indicate the following:
• Alarm state
• Alarm priority
• Alarm message
• Date and time of alarm occurrence
Apart from the above, each alarm may also indicate the following:
• Alarm tag
• Set value transgressed
• Present value of the alarmed variable
• Peak value of the alarmed variable
The alarm messages should be designed with great care. The alarm messages should be simple and
easy to understand for the operators. The operator should know how to respond to the alarm after
understanding it. The state and priority of the alarm may be indicated using a combination of text,
symbol, color, brightness and position coding with the most important marker being the most
conspicuous. However, due to the possibility of the operator being impaired to color codes or color
vision, use of color coding alone should not be used. Utmost care must be taken during designing an
alarm message so that the most valuable information for the operator is highlighted and not missed-
out. Some of the characteristics of a good alarm message are:
• It clearly identifies the condition that has occurred.

• Its terms are easy to understand and the operator is familiar with these terms.
• It uses consistent and standard abbreviations from the standard dictionary of
abbreviations prepared for the plant/site.
• It has consistent message syntax or structure.
• It does not involve tags numbers or equipment numbers; otherwise the operator has to
remember Tag numbers or equipment numbers.
• It has been checked for usability during the plant operation.
During the plant operation, an operator will receive many alarms and have to read many alarm
messages. The font size of the alarm message should be chosen such that the message is easily
legible. The size of the font for the alarm messages should be larger than the size recommended
from an ergonomic point of view for legibility for the operator working in normal position. The
alarm message page layout should be designed in such a way that it is easy for the operator to
remember the position of a specific alarm. Dividers between alarm messages are quite useful. Any
new entry in the alarm list display shown must be indicated blinking/flashing to get the immediate
attention from the operator. Preferably a blinking star (*) before the alarm message text should be
used and blinking/flashing of the alarm message text should be avoided. Once the alarm is
acknowledged or accepted by the operator the blinking/flashing indication should be stopped and
shown steady.
2.8.3 Positioning a new alarm in the alarm list

The alarm display should be designed in such a manner, that the operator should loose the view of
the alarm message list only when he wants to and he changes the display. To design an alarm list
display to the satisfaction of operator requirement, automatic scrolling, movement from one to
another or removal of alarms should be avoided. If an alarm appears on the display, it should remain
fixed at that position until the operator responds to it. Such alarm displays are called page-oriented
alarm displays. The alarm list is filled with alarms as they occur. When an alarm page is filled with
alarms, new alarms are added in the next page and an indication is provided that there are more
alarms on the next page. It is useful if an indication is provided that there are unaccepted alarms on
the next page, or the highest priority of alarm on the next page is indicated. The operator has to give
a command from a keyboard or touch on smart-target for going to the next page or previous page of
the alarm list. Though, page-oriented alarm list displays are preferred, in practice, scrollable alarm
lists displays are also used in industries. In a scrollable-list display, the most recent alarms are
displayed at the top position and the list scrolls downwards as the most recent alarm occurs and
occupies the top position in the alarm list.
2.8.4 Accepting alarms

The operator should be able to accept individual alarms on the list and also all the alarms
unaccepted on the alarm list display. Acceptance of an alarm involves both acceptance of the alarm
on the display list as well silencing of audible warning. In some alarm systems separate buttons are
provided for accepting alarms on the display list and silencing audible warning. This helps the
operator in eliminating the nuisance from audible warnings and then accepts the alarms on the
display after completing the investigation. Separate buttons also help the operator to manage heavy
alarm loads during large plant disturbance/upset. Accepted or cleared alarms should be displayed in
medium conspicuity and should be annotated to indicate the clear state of the alarm.
2.8.5 Moving through alarm lists
Movement through the alarm lists should be in the operator’s control. Usually, the following
controls are provided for movement through the alarm lists:
• Move to start or end of the list
• Move to view unaccepted alarm in chronological order
• Move down or up the list-by moving line-by-line, scrolling, or page-up/down.
• Move to previous page / next page of the alarm list
• Go to alarm list page / display by page / list number
2.8.6 Removing alarms
It should be possible for the operator to remove alarms from the list only when the alarms are in the
reset state, except when they are shelved. Alarms are reset only when they are accepted and cleared.
Reset alarms should be displayed in low conspicuity. Only the operator should remove reset alarms
from the list. In some plants, the operator installs ring-back alarms that require clearance and
acceptance of rising of certain alarms. The ring-back alarms are reset only when their clearance is
accepted. Only a limited number of ring-back alarms should be used as these alarms increase the
operator’s workload.
2.8.7 Handling nuisance alarms
The operators often have to handle low operational value nuisance alarms. The low operational
value standing alarms cause nuisance. Repeating alarms also cause serious problems on alarm list
displays. The alarm list display is overloaded with repeated alarms making it difficult for the
operator to view the alarms having significant operational value. An alarm list display should be
designed keeping the following points in mind to ensure that repeating alarms do not make alarm
lists unusable:
• Each alarm should be designed carefully to ensure that no spurious repeating alarms are
generated.
• To ensure that repeating alarms do not make the alarm list display unusable, single line
annunciation should be provided.
• For alarms derived from analog signals, adjustable dead band should be provided.
• Provision for manual shelving of alarm.
2.9 Filtering alarms

When a large number of alarms occur within a short period, it can be difficult to identify the faults
in a single alarm list display. This is a disadvantage of the alarm list displays when compared to
alarm annunciators, which makes it easy to recognize alarm trends. Filtering alarms helps in
displaying/viewing smaller and manageable alarm lists for the operator. Alarms are filtered based
on the following (one or more) criteria:
2.9.1 Category of alarms
Grouping alarms in categories based on plant sections, sub-sections or units or groups and providing
facilities to select alarm lists filtered on these categories. For example, a continuous dry process
cement plant is divided into four sections – Raw grinding section, Pyro-processing section, Coal
grinding section and Clinker grinding section. Alarms related to each section are grouped into four
categories. Alarms related to raw grinding section of the plant, are filtered based on the
category/group and displayed in the alarm list display for raw grinding section operator. So, all the
alarms in the plant are categorized/grouped into four alarm list displays, each for one section of the
plant.
2.9.2 Priority of alarms
Filtering of all the alarms generated in the plant based on the alarm priorities helps in identifying
important critical or high priority alarms. For example, in an all alarm list for a cement plant it may
be useful to filter alarms and display a list of critical priority alarms for immediate operator
attention.
Unaccepted alarms: In some systems, suppression of repeated alarms results in alarm listings in
non-chronological order. In such cases when the operator needs to view only unaccepted alarms, the
filtering of alarms to these criteria is quite useful.
Shelved alarms: List of shelved alarms is generated when alarms are individual or group of alarms
are shelved. Shelving is one of the ways of filtering out nuisance alarms from the all-alarm list.
Mode of plant operation: At times, some of the alarms are useful only during one mode of the plant
operations and these may not be useful during the other modes of operations of the plant. Hence,
such alarms are filtered out by detecting the mode of the operation of the plant and are suppressed
during this particular mode of operation.
Predefined named lists: For performing specific tasks during plant operations, it may be useful to
have predefined filters so that only the alarms related to that specific task are displayed.
2.10 Additional information for operator

In the alarm lists, additional information can be provided to guide the operator to take corrective
actions, possible alternatives to select from, outcome of action chosen & probable consequences,
feedback on effectiveness of action taken, etc. It is important for the operator to have quick access
to the following displays:
Schematic of plant area: In some SCADA alarm systems, screen icons or dedicated keys are
provided for accessing the schematic display of the plant area associated to the alarm.
Trends: Historic trends of process variable alarmed and other related process parameters. Groups of
up to 8 parameters for Group Trend displays can be pre-configured and called up by the operator by
simply selecting a screen icon or entering the Trend Group Number (single or two digits).
Control Panel: A control Panel related to the plant problem can be brought up for the operator to
take immediate action.
Action(s) to be taken: Information on what actions to be taken and operation procedures with more
details on the alarm response procedures.
Information on alarmed variable: General information related to alarmed variable, such as – tag
number, group or plant section/area, alarm settings, dead band, method of alarm detection, normal
operating range, PLC address, etc.
Alarm and event log: The operator is provided access to the historic list of alarms and events. This
helps the operator to analyze the sequence of events that have occurred before the plant/equipment
trip.
2.11 Alarm Review

Although it is a time consuming process to generate a database for large number of alarms in a
plant, it is important that design issues for each and every alarm are resolved and documented
before configuring the alarms. Following are some questions that need to answered for each and
every alarm and can be considered as minimum design documentation:
• What is the purpose of the alarm?

• hat response is required for this alarm from the operator?
• In case the operator does not respond to the alarm, what can be the likely consequences?
• How much time is available for the operator to respond to the alarm?
• What will the effectiveness be of the operator response?
The above questions can be used as basis for an alarm review at the later stage when plant is
operational and improvement in alarm system is needed to improve the overall performance.
2.11.1 What is the purpose of the alarm?
• It is important to know what the purpose is of the proposed alarm and for what hazards
or risks it will provide a warning or an alert to the operator. The consequences of alarm
failure or the alarm being missed need to be identified. If the proposed alarm provides
only information of an event/incident, then it should not be configured as an alarm.
• Assessment of severity of the risk in terms of potential loss of life or an injury,
economic losses, environmental impact and plant damages must be done. Any hazard to
people should be in the form of formal risk assessment for the plant. Economic risks,
potential plant damages or losses should be expressed in terms of financial losses.
• Expected frequency of the risk occurrence should be estimated. Though it is difficult to
know the accurate chances/frequency of occurrence, it may be appropriate to have some
approximate estimate that is more realistic. Appropriate frequency of occurrence may
be specified as once a week or once in month, etc.
• Are there any other protection systems in the plant to provide protection against the
risk? If not, then whether an automatic protective system can be used with or without
configuring the alarm.
• Are any reliability claims made in the plant safety case for protection provided by the
alarm? Do these reliability claims require the alarm to be classified as safety related
alarm? If an alarm is not safety related, then what are the economic and/or
environmental risks involved in implementing the alarm within the process control
system? Safety related alarms should be implemented outside the process control
system, unless the control system itself is safety related. At times there may be
ergonomic advantages along with reliability reasons for displaying some
economic/environmental significant alarms on individual or standalone alarm
annunciators.
• It is important to know the implications of alarm failure due to alarm sensor/instrument
failure. How to detect these failures and how to validate the alarm signal? Should the
alarm sensor/instrument have redundancy?
• How effective will the operator response to the alarm be? If the operator cannot take
any corrective or preventive action to prevent the risk, then the alarm hardly provides
any benefit and should not be configured as an alarm.
• While responding to the alarm, what stress is the operator subjected to?
2.11.2 Operator response

• What should the response of the operator be to the alarm? The response may be an
action, a conditional action or only a cognitive switch. The response must be clearly
defined for each alarm. It must also be identified whether the defined response is to be
changed/altered with changing plant/equipment conditions.
• The alarm message should be easy to read and understand. Guidelines should be
developed for standard format of alarms messages and for abbreviations and terms to be
used in the alarm messages. For example, an alarm–‘Raw mill outlet temperature high’
may be abbreviated as ‘RM O/L TEMP HI’. In some cases, tag numbers are preferred
instead of text descriptions. For example, if the raw mill has been assigned equipment
number 2000 in the plant, and the outlet temperature transmitter is tagged as TI2000
and the raw mill outlet temperature controller is tagged as TIC2000, then tag ‘TI2000H’
can be used to denote the alarm ‘raw mill outlet temperature high’ and the tag
“TI2000HH” to denote the alarm ‘raw mill outlet temperature high high’.
• If required, develop additional displays that give information required by the operator to
decide on how to respond in different conditions of the plant. During different plant
conditions additional text messages and detailed graphic displays may be provided to
present detailed information.
• How long will the operator take to respond to the alarm and how long will the plant
take to respond to the corrective action(s) taken by the operator. In cases where the
cause of alarm and the corrective action to be taken is known, then better operator
support tools may be needed. Assessment of expected response time also helps in
estimating the acceptable rate of presenting the alarms.
• Procedures for alarm response should be prepared and provided to the operators.
2.11.3 Alarm prioritization

• The likely safety, economic and environmental consequences of the operator not
responding to the alarm should be assessed.
• Identify whether the alarm is time critical and what is the time available for the operator
to respond to the alarm. For example, an alarm may be considered as time critical if its
consequences cannot be avoided where the operator does not take corrective action
within 3 minutes.
• Depending on the severity of safety, economic and environmental consequences of
missing the alarm and/or not responding to a time critical alarm and how fast the
operator is required to respond to the alarm, priority should be allocated to the alarm.
• It should be determined whether it will be required to change the priority of the alarm
depending on changes in the operating conditions.
2.11.4 Alarm settings
• What is the normal range for the alarmed process variable? What should be the alarm
settings for alarming the safety hazard, and/or economic losses and/or environmental
damages?
• How many alarms should be set for the process variable–Low, low-low, high, high-high
and what should be settings for these alarms?
• Is there a need for changing the alarm setting depending on plant operating conditions?
• During normal plant operation, what are the fluctuations in the process variable to be
alarmed? What are the fluctuations in the process variable during plant disturbances and
upsets? What size of dead bands should be used for generating alarms?
2.11.5 Alarm suppression

• If the alarm will be generated during large disturbance/upset in the plant or during plant
trips, then the alarm should be suppressed using a suitable logic.
• If other alarms having more significance occur, the alarm should be suppressed.
• Are there any conditions during which the process variable will cross the alarm setting
but there will be no risk involved? For instance, during a pump start-up, the current
drawn by the motor initially may shoot up momentarily, exceeding the current high
alarm setting for normal condition of the pump running.
• What signals should be used for logical suppression of the alarm?
• What are the chances of the process variable going out of range or being invalid? How
it will affect the alarm. Will it create a nuisance or repeating alarms? How such
situations should be made known to the operator or how to avoid plant/equipment trips
if the process variable alarm limit/Flag is used for plant/equipment interlock.
Various alarm suppression techniques are used to determine whether the alarm signals are
appropriate for display to the operator or not. Alarm suppression techniques should be applied with
great care as often safety related problems arise due to inappropriate application of suppression
techniques on safety related alarms.
Suppression techniques can be used for reducing the alarm priority rather than eliminating the
alarm:
• Redundancy logic: Often more than one measurement are made for a process variable and used
for majority voting in safety systems. If alarms are generated from each of these measurements then
there will be multiple alarms generated indicating the same event/fault. In such situations,
suppression logic is used to ensure that only a single alarm is displayed to the operator. Sometimes,
even same alarms are generated by different alarms systems. It may be useful to suppress such
duplicate alarms without compromising on the integrity of the alarm.
• Eclipsing: At times there are several alarms generated from a single process variable. Such as–
water tank level low alarm and another water level low low alarm at a slightly lower setting.
Suitable logic can be used to suppress alarms with lower significance when more significant alarm
has been raised. In case of water tank, level low alarm may be suppressed when level low low alarm
is raised. Eclipsing may result in fewer alarms being displayed to the operator but it may not always
result in fewer alarms that operator has to accept.
• Plant/Equipment out-of-service: Some of the alarms are relevant only when the plant/equipment
is in operation. For example, when an air compressor is stopped for preventive maintenance, the
compressed air pressure low alarm has no relevance. Such alarms, which may not be relevant when
the plant/equipment is out of service, may be suppressed using a suitable logic. Sometimes, the
priority of such alarms is reduced for just logging the event in the Journal and the alarm is not
displayed to the operator. The operator should be provided with a list of suppressed alarms and
should be able to override suppression, if required.
• Operating mode: As discussed earlier, some alarms are relevant during a particular mode of
operation of the plant. If there is lot of irrelevant alarms generated during a particular mode of the
plant operation, it may be required to suppress alarms or make some changes to alarms settings
during the particular operating mode of the plant. For example during a cement plant start-up it may
be more difficult to control dust emission levels from the Chimney than when the plant is stable
operation. Following are some typical modes that can be used for used for suppression of such
alarms:
• Plant start-up
• Plant operations stable
• Plant shut-down
• Plant under maintenance
• Different stages or different recipes in Batch processes
At times, the transition between the various modes is not clearly defined and changes from time to
time. Also at times, different alarms may be relevant at different stages in the transition and may
depend on the direction of the transition. Hence, the suppression logic must be designed with utmost
care. It is good to do carry out logical processing for suppression based on identification of mode
and inform the operator about the mode change and seek his/her confirmation.
• Major plant disturbance/upset: After a major system disturbance/upset, the operator is

overloaded with alarms. Major system disturbances or upsets are relatively hazardous periods of
plant operations and pose lot of stress on the operator. It is quite important that the effectiveness
and performance of the alarms is improved for this period. This can be done during the priority
allocation or alarm improvement programme. Many alarms that occur after a major system
disturbance/upset are related to events that are expected to occur. During, a plant shut-down,
tripping of many inter-related equipment is expected and many process parameters will go beyond
their normal operating ranges. So, suitable logic for suppression of such expected alarms can
provide significant reduction in load of expected alarms having less operational value for the
operator.
2.11.6 Management of alarm settings

• Procedures for making changes in the alarm settings. Who should be authorized to do
the changes in alarm settings?
• Generally, an alarm shelving facility should be given to the operator. However, in some
plants the operators may not be authorized to shelve alarms due to various safety or
other reasons. Special procedures may be made for shelving critical and important
alarms.
• Does the alarm need testing, if yes then how should the alarm be tested and how
frequently. How should the alarm be maintained?
2.12 Alarm management best practices

Best alarm management practices involve the following steps:
• Create and document an alarm philosophy: this process can be as valuable as the
document itself. It helps standardise the configuration across multiple lines, especially
where pipelines have been acquired rather than built by the operating company.
• Benchmark and performance audit: each of the KPIs defined in the alarm philosophy,
which may match those of EEMUA 191 where they are applicable, are calculated and
interpreted. To complete the audit, the alarms and events must be historised in a fashion
that allows for alarm and event analysis.
• Rationalise alarms: clean up bad-acting tags, which can contribute up to 50% of the
daily alarm load. Alarm rationalisation involves a team of people from operations and
engineering, together with an impartial facilitator to methodically review alarm settings
on each alarmable SCADA tag.
• Investigate dynamic and state-based alarming: this is not a simple activity and takes a
solid understanding of the operational and control philosophies of the facilities during
all relevant states.
• Implement changes: based on results of rationalisation and investigation.
• Continuous improvement: alarm management has a life cycle and is not a one-time
project. Continuous performance monitoring helps to identify new opportunities for
improvement.
• Manage change and corporate culture: organisations successful at alarm management
integrate the practices into the workflow to optimise performance over the long term.
2.13 OPC Alarm and Events

The OPC specifications, introduced in Part 2 Chapter 8, include specifications for handling Alarms
and Events. The OPC Alarm and Events (OPC AE) specification defines an interface between a
client and server for monitoring alarms and events. The OPC AE server reads data from various
sources and determines whether an alarm condition or other notifiable event has occurred. The
server can get this data directly from the process data sources or from another OPC Data Access
(DA) server.
The OPC AE server has interfaces which enable an OPC AE client to:
• Determine the types of alarm conditions or events that the OPC AE server supports
• Enter subscriptions to specified alarm conditions or events, so that the OPC AE client is
notified of their occurrences.
• Specify a client callback interface to be invoked if the OPC AE server is shutting down.
OPC AE clients are typically used to subscribe to and display, process, collect and/or log alarm and
event information available from the AE servers. Some examples of applications for OPC AE
clients are:
• Operator stations
• Event and alarm logging components
• Event and alarm management components
OPC AE clients are able to send an acknowledgement back to the server. In this way multiple
operators can work with one server and the server has the information about when the condition was
acknowledged and by whom. Clients are also able to change the enable attribute on the condition
object so that the OPC AE server will no longer check for this condition in the event of equipment
being temporarily taken out of service. The condition object also has a severity attribute defined in
the range 1 to 1000 which is used to indicate the severity of the condition and can be used for
prioritisation of alarms.
OPC AE allows an open-source alternative to integrated alarms within a SCADA package.
2.14 Further Reading

For a more comprehensive discussion of alarm management issues the reader is encouraged to read
the IDC Technologies publication Practical Distributed Control Systems (DCS) for Engineers &
Technicians.

ECQ75Units5 6 All

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ECQ75Units5 6 All

Caricato da

Copyright:

Formati disponibili

Certificate in PLC’s and

E-mail: eit@eit.edu.au Web Site: www.eit.edu.au

In this chapter, we will learn the following:

• Introduction to PLC installation

7.1.1 Interference and noise

7.1.2 Sources and types of noise

Now we will discuss the installation requirements in each area.

7.2 PLC modules

7.2.1 Keying of module

7.2.2 Handling of memory chips

7.2.3 Selecting voltages for I/O modules

Voltage range of input/output module

Minimization of power consumption/heat generation

Leakage current/earthing and grounding problems

Loop powering of field devices

7.3 PLC rack

7.4 PLC panel internal wiring

7.5 PLC panel power supply

It is important to size transformers correctly:

7.6 Cabling between PLC and field devices

7.6.1 Shielding wire

7.6.2 Cable spacing

• If the cable is likely to run a considerable distance, a calculation should be

7.6.3 Wiring levels

• Level 2 - Medium Susceptibility

• Level 3 - Low Susceptibility

7.6.4 Wiring class codes

7.6.5 Tray spacing

LEVEL 1 2 3 3S* 4 4S*

7.7 Cabling between PLC and control room computers

7.8 PLC earthing

7.9 Specific PLC installation requirements

7.9.1 Reed relays, electromechanical relays and solenoids (DC only)

7.9.2 Solidstate relays

7.9.3 Switch inputs

7.9.5 Interposing relays

7.9.6 Safety circuit

7.10 Control room requirements

A few issues to assess in the design of the control room are:

7.10.1 Environmental considerations

ENVIRONMENTAL RECOMMENDED RANGE

7.10.2 Typical control room layout

The voice communications system (either radio or telephone) should be situated as

7.10.4 Sound environment

7.10.6 Colours of equipment

Ah, yes—the equipment manuals.

• Tells readers what they want to know.

19.1 What is a Manual?

Most online manuals now have three levels of help:

19.2 Types of Manuals

• P&IDs (Piping and Instrument Diagrams),

• individual standard manuals for individual standard components, and

Engineer Manual Created by Followed by Purpose is to explain...

Installation Supplier Installer How to install the control system

Commissioni Supplier Supplier’s How to commission the control system

19.3 Planning the Manual

• Define your reader

19.3.1 Define your reader

• Has never used a computer

• ‘Getting Started in Databases’ for inexperienced operators

Has never used a

Has entered data in other z z z

Has viewed data in other z z z