Alarm Access
A High Performance HMI is designed to minimize the number of keystrokes required to identify, verify, assess, and respond to an alarm.
Every point with a configured alarm should have an associated Level 2 or 3 graphic display on the DCS. This associated display should aid the operator in the proper diagnosis and mitigation of the event causing the alarm. Methods by which the operator is quickly directed with a single keystroke or button-click (i.e. one-touch access) to the associated display should be used. Most DCSs have this capability, but it must be configured.
A more sophisticated implementation is possible once you are at the appropriate Level 2 or 3 display. When an item comes into alarm, the display can be configured to show not only which value is in alarm, but to also highlight predetermined items associated with the alarm, which should be the ones needed to respond.
A single alarm interface should be used, namely, the DCS. If alarms can come from sources nominally “outside” of the DCS, those should be brought into the DCS if it is used in any way to respond to the alarm. All alarms should be acknowledged only once; it should never be required to acknowledge the same alarm using more than one methodology.
A process graphic must visually and consistently identify tags in alarm, whether the alarm is acknowledged, and the priority of the alarm
Audible Alarm Indication
Every alarm priority chosen should have its own unique alarm sound. In a control room with several operating positions and consoles, this could pose a difficulty. If closely adjacent consoles have the same sounds, then the operator cannot use sound to detect a new alarm on their own console.
The solution is each console can use its own “family” of sounds for priority. It is also possible to use lights; we have seen consoles topped by a small stacked cylinder of three or four lights, with colors matching the alarm priority colors. These lights activate either instead of or along with the appropriate sound. In this way, if the sound volume is kept down and if one operator is having a discussion with another operator at their console, the lights help indicate the presence and location of a new alarm.
Guidelines for the effective use of sound are:
Sound level should be enough for easy detection, but should not startle the operator. A value of 15dBA above background noise is about right, but should not exceed 80 dBA. A sound starting at a lower level then rising in pitch and intensity can be very effective. Most DCSs are no longer constrained to hardware “beepers” for alarms, but can utilize any sound file saved on the computer – even voice.
People vary in their hearing ability. Some have hearing loss specific to certain frequency ranges. Ensure, via testing, the sounds and the volumes work with the operators.
Small, wireless earpieces or lightweight headphones are a fairly recent development and can be used to send sounds only to a specific operator. (Covering only one ear is preferred.) Frequent testing of the devices is necessary (consider the batteries). A hardwired light can be substituted for the external alarm sound to indicate the presence of a new alarm and this should be used as backup, since the earpiece is a single point of failure. It is never desirable for an operator to miss an alarm.
It should be possible to turn off the alarm sound for the lowest alarm priority during periods of high alarm loads. The operator doesn’t want or need a continuing distraction from the low priority alarm sound during a major upset. Visual notification should remain in place. This practice must NOT be left in effect all the time. It should have a timeout feature after a few minutes.
The preceding principles assume proper alarm management practices have produced a rationalized, meaningful, and effective alarm system. If a system is generating 500 (or 20,000+) alarms per day, sound becomes a nuisance distraction.
We often see these basic principles violated. We see “alarm colors” used for all kinds of different graphic elements and single alarm sounds assigned to multiple priorities. Even worse, we see priorities with no sound at all – making it much less likely an operator will initially see such an alarm. The result of such configuration decisions will be an alarm system HMI which is less effective in helping the operator to properly detect, identify, and respond to alarms.
Be careful who you listen to!
It is surprising to learn some people claiming expertise in HMI design advise to use only a single alarm sound for all alarm priorities. They say, “With more sounds, the operator will get confused!” Well, would you want your telephone, pager, cell phone, alarm clock, doorbell, and microwave oven to share the exact same sound? No. An important purpose of sound is to differentiate. It would be easy to test this misguided advice. Imagine if you select 100 different sounds from various events, television shows, and movies, such as:
The first four whistled notes from The Andy Griffith Show
The static-filled scratchy spoken sentence beginning
“That’s one small step…”
R2D2 “speaks” in Star Wars
The opening orchestral notes from I Love Lucy
The tick of the stopwatch used in 60 Minutes (or the one in 24)
The sound effect of the Star Trek transporter or communicator
The first 4 notes from the opening of The Twilight Zone
As you read these, you probably imagined the sounds. (Many people can sing all the verses from Gilligan’s Island – an ability they never specifically sought.) You could play these sounds for a variety of test subjects and the recognition score would be quite high. This is true even though the exposure to these sounds is far less than will be encountered by a trained operator working with a console for 12-hour stretches. People readily remember and associate sounds and have little confusion doing so. Use sound effectively!
Voice Rather than Sound?
DCSs may have the capability of using voice (usually via .wav file) rather than simple sounds for alarm annunciation. (Fighter aircraft use this capability and a female voice was chosen after extensive ergonomic and audibility study. Pilots, however, have a derogatory name for this system, one that we shall not repeat here.)
The use of voice capability must be approached carefully. Consider a 3 priority system with 3 well differentiated “beeps” indicating a new alarm of the corresponding priority. This is a very fast and low-distraction notification of a new alarm and its priority. To use voice instead, there must be some additional benefit justifying the extra time and “interruptive” nature of a voiced alarm.
To use voice, it is also necessary to have your alarm system under control and have low alarm rates.
If the 3 beeps were replaced with a voice saying either
“Priority 1 alarm” or “Priority 2 alarm” or “Priority 3 alarm”
then little value has been added. If the alarm rates are high, then a very annoying distraction has been created.
However, if voice can be used to differentiate something like:
“Compressor Priority 2 alarm” or
“Heater Priority 3 alarm” or
“Raffinate Priority 1 alarm” then extra information possibly yielding more benefit has been added. But, this may be difficult to implement. Voice should not read out each individual alarm, as in “EFF CEE One four zero one dash one five Splitter Inlet Flow Hi Rate Alarm Priority 2,” because that message is more quickly read than heard.
Additionally, there is the whole issue to deal with about the voice repeating until alarm acknowledgement. Reading from the display can be done at the operator’s discretion since the message will stay there. The operator can finish typing in a setpoint change and then read the alarm. Listening, however, has to be done when the speaking is occurring, and is thus more of an interruption.
Therefore, the use of voice rather than sound for alarm annunciation needs considerable thought to be done correctly.
Objects and Symbols
Develop standard shapes and sizes for vessels, instrumentation, pumps, heaters, heat exchangers, interlock symbols, etc. Make use of pattern recognition so objects can be identified at a glance.
Proper labeling should not be intrusive or of high visibility. Use consistent methods for labeling vessels, pumps, motors, navigation targets, and similar items. Note, every item does not require a label; identification by context is often adequate. In particular, tagnames or point IDs should not be routinely displayed on a graphic; they merely add unnecessary visual clutter.
The examples shown throughout this section incorporate depictions consistent with these guidelines.
7.24 Process Controllers
There is much variety in the depiction of a process controller. Many people equate a controller with a valve and associate the controller information (setpoint, process value, output value, mode, etc) right next to, and often indistinguishable from, a controlled valve. This is a poor practice.
A controller should be thought of and depicted as a physical entity, similar to a pump or heat exchanger. (We know it is only a software construct in the DCS, but in thinking about the process, the operator’s mental model should represent it as a separate “thing.” Proper graphics should promote proper mental models.) Controllers do not just control a single valve but also multiple elements and even other controllers. By depicting a controller separately, proper information about its operation, status, and connectivity can be clearly shown. If it is part of a larger control scheme, perhaps involving cascades and programmatic elements, a more complete depiction of the control scheme can be designed, yet be consistent with the depiction of simpler schemes. Linking controllers conceptually to control valves is far too limiting.
The depiction of controller elements poses a significant problem in “where to stop.” The DCS construct of a controller may involve several dozen different parameters, as shown in Figure 7-27.
To depict a controller on a process pictorial therefore involves some substantial editing. An effective depiction will show only four items, with more detail available via the faceplate-type display. These items are:
- Controller Process Value (PV or P) – The current reading of the process value being controlled, generally in Engineering Units.
- Controller Setpoint (SP or S) – expressed in the Engineering Units of the PV.
- Controller Output (OP or O) – expressed as a Percentage, generally within -7% to +107%.
- Controller Mode – generally Automatic (AUTO), Manual (MAN), Cascade (CAS), or a few other specialty modes in some DCSs.
Figure 27: A Typical DCS Controller With More Than 80 Parameters
The depiction should be simple, straightforward, and consistent. Hundreds of different options are available, but the tendency to try to cram too much information via tiny symbols and cryptic abbreviations must be resisted. Figure 28 is a good example.
Figure 28: A Simplified Controller Element for Graphics
In Figure 28, the four main controller elements are shown, along with an alarm indication and a space for a short, descriptive title. (Do not use the title area for only a meaningless tagname.) The units of measure are shown. The presentation is compact. “Live” values of PV and OP are shown and the Setpoint is subtly distinguished in a dark green. Attempting to incorporate a tiny analog scale in conjunction with a controller depiction, such as this, is generally futile. The scale is just too small.
The slight color difference for Setpoint is not very significant – it is more important that the relative placements be consistent. The intent of the color difference is to distinguish between measurements sensed by the system and operator-changeable values. This difference should be consistent across other types of control elements as well.
Simplicity is the ultimate sophistication.
Amy B. Smith (MIT) quoting Leonardo da Vinci
A click of the simplified controller element should bring up a faceplate as shown in Figure 7-29. The faceplate has more detail and the ability to alter setpoint, mode, output, and other operator-adjustable parameters. Graphic faceplate elements for all DCS point types are usually provided from the manufacturer. It may or may not be possible to alter them and they may not follow other principles in your high performance displays. Improper use of color is a common fault in vendor faceplate elements. Rebuilding or replicating dozens of standard faceplates from scratch to correct minor consistency issues may not be worth the effort since future vendor software upgrades may override the work. Moving analog indicators modified to show the additional controller functionality are also practical for many uses.
Figure 29: Progressive Exposure of Controller Detailed Functionality
Control Valves and Shutoff Valves
There is also much variety in the depiction of valves. Again, the tendency is to cram too much data into a small space. Avoid tiny scales to show output percentage, variable shading or color depending on valve condition, and other such efforts. Make consistent decisions as to what controller output is a “closed” vs. an “open” valve. One-click access to the controller or valve faceplate will reveal this type of information when needed by the operator.
In a few cases, a single controller affects multiple valves via split-range techniques. In such cases, numerically showing the open percentage next to each valve may be useful. This appears to contradict the principle that raw numbers should be avoided, but a percentage number is very easily and quickly interpreted, and other solutions to this issue are usually far too complex. Figure 31 illustrates this.
Figure 30: Simple Valve Depiction
Figure 31: One Controller with Multiple Valves
Instrument Lines
The process connection to a controller should be shown as a one-pixel, solid, dark gray line. The connection from a controller to its final control element(s) should be a one pixel dashed dark gray line, when this is practical. Do not clutter a display with instrument lines – an HMI is not a P&ID. It is useful to show the connection between controllers when a cascade loop is in effect.
Depicting Dynamic Equipment
It is important to properly show the current condition of equipment that can have multiple operational states. State depiction should not depend on color, but upon fill status, shape, or even simple text. The depiction must differentiate between equipment whose state is signaled to the DCS versus similar equipment not so equipped. The depiction of pumps is a common issue illustrating all of these factors.
Figure 32: Pump Run Status Depiction
It is also possible to depict state with a simple text string next to the pump of “RUNNING” or “STOPPED”, as shown. The running pump should not be shown as “green” and the stopped pump should not be shown as “red.” Color is used to bring attention to abnormal situations. There is nothing inherently abnormal about a pump either running or not running.
Indeed, there should never be an alarm on a pump simply because it is not running. There should possibly be an alarm if the pump is not running when it is supposed to be running. This is a logical alarm design differing from the usual, poorly implemented “Off-Normal” type of alarm.
Selecting the pump should bring up the command possibilities via the faceplate.
Depicting Equipment Commands
When DCS points are built that indicate equipment state, the control engineer can usually decide what words should be displayed to represent the current state. The choices they make are often poor. The most common example is “RUN” and “STOP.” Do these represent the equipment’s status or a command to it? “RUNNING” and “STOPPED” are much better status indication words. “STOP” and “START” are commands, not statuses. Similarly, the graphics need to clearly differentiate between status indications and command possibilities.
Display Layout
Displays need a consistent “look and feel.” Different DCSs have unique embedded structures and paradigms around the location and type of navigation abilities, faceplaces, “change zones,” programmable keys, etc. These features should be implemented in such a way as to comply with the principles of High Performance displays.
It is important to use these built-in abilities to their maximum potential. It is inadvisable to attempt to make a “Brand XYZ” DCS look like a “Brand ABC” – the results will usually be far from optimum. This is true even if you are migrating from one DCS type to another; learn the new paradigms embedded in the new DCS rather than trying to custom-build your old DCS structures on top of the new system.
Displays should be clean and uncluttered. Build and use standard display layout templates showing common items for each type and level of display.
Navigation
Multiple methods of navigation should be provided. The operator should be able to go up and down through the hierarchy, side to side through the process, and call related details, trends, and shutdown status displays from any graphic. This navigation capability should work with all available methods provided for navigation by the DCS vendor – mouse or touch screen target selections, keyboard keystrokes, context sensitive menus, etc.
The system and graphics should be configured so it is never necessary for the operator to type in a point name or graphic name. The ability to get to any graphic without knowing the hierarchy should be available for maintenance and engineering users of the system; this may include an overall menu or direct entry of graphic names displayed/printed with the graphic.
Most DCSs have arrays of programmable keys, which can be assigned to call up certain displays or combinations of displays. Such key arrays should be arranged logically and match the hierarchy of the HMI. Preferably, all Level 2 displays should each have a dedicated key. The most commonly used Level 3 and 4 displays should get the remainder.
Create a standard naming convention for graphic files and embedded display files. Use clear, descriptive names identifying the process and hierarchy. However, it should never be necessary to type filenames to navigate. Show the graphic name on the display unobtrusively.
Yoking
Yoking is a display arrangement concept. The intent is to create an optimal arrangement of graphic displays on multiple physical screens for a particular situation. This arrangement is saved and made recallable with minimum keystrokes. It is of great use in dealing with time-sensitive abnormal situations.
Shutdown Actuation
Operators must generally be able to manually and quickly shut down operating equipment. However, when an important action with significant consequences is based upon operator input, the input should have a confirmation mechanism that avoids inadvertent activation. The “cancellation” option should be consistently implemented.
It should never be possible to make a single selection on a screen that results in an inadvertent shutdown. A “Shutdown button” should call up at least one and perhaps two layers of confirmation before it is possible to actually cause such a significant event.
The “defaults” of such mechanisms should be on the safe option. Always consider what an inadvertent “ENTER” will do and label screen items with full clarity.
Figure 33: Layers of Confirmation
Major process upsets have occurred by mistyping an input (for example, opening a slide valve to 47% instead of 4.7%). DCSs using membrane keyboards are particularly susceptible to this type of error. Error checking methods should be used to require confirmation of numerical entries that seem inappropriate.
Call-Up Speed and Performance Expectations
Graphics used for operational purposes should display quite quickly when called up. Graphics taking longer than 3 to 5 seconds to appear become frustrating. However, since almost all high-performance graphics should have certain trend information, this may be a challenging goal, as trends often take a few seconds to populate. There are methods by which the simpler content can be displayed first and then the trends, which will somewhat alleviate the “blank screen” frustration.
Screen updating of depicted values should relate to the speed at which the process is capable of change. The need is to avoid excessively high update rates. These can be distracting and also generate unnecessarily high bandwidth utilization on the DCS network.
An update rate of up to twice the rate of significant process change is the maximum recommended. For most typical industrial processes, an update rate of every 2 to 4 seconds works out fine, with one-second updates chosen for particular things by exception. Sub-second update rates are not very usable by the operator; a screen displaying jittery numbers is a distraction, not a help. This is particularly true if the changes are only in the fourth and fifth decimal places of the value, which is a separate issue previously addressed.
DCS Bandwidth, Loading, and Errors
Many DCSs are surprisingly low-bandwidth devices. This arises from the legacy nature of their network architectures and the need for backwards compatibility. Many engineers carry a cell phone having much higher bandwidth than their multi-million dollar DCS. The DCS designers have to allocate limited bandwidth to various system tasks.
Alarms are one of the high-priority users of bandwidth. DCSs are capable of generating and saving hundreds of thousands of alarm events per day. In some cases, we have seen bandwidth maxed out by alarms that have been suppressed and not shown to the operator, and thus not presenting a visible symptom of the problem.
A variety of problems can begin to appear when bandwidth utilization approaches the maximum capacity. Lower priority engineering-related tasks, such as program operation and compilation, data extraction, and calculations may begin to fail in unanticipated and unrepeatable ways. This can produce obscure and inconsistent errors and data gaps. If you are experiencing such problems, check your DCS bandwidth utilization.
Depicting Material Balance
There have been at least two major process accidents where large amounts of flammable materials flowed from the process into systems not designed to handle them. These large flows went undetected by the operators for many hours. A properly implemented mass balance or volumetric material balance calculation could have detected these situations and should be part of an overview display and relevant Level 2 displays. Figure 34 shows two examples with explanatory labeling. These could be made more compact in actual practice.
The more compact example on the right incorporates a bar growing upwards or downwards from a center zero based upon the accumulated positive or negative difference. An alarm indication is shown based upon the calculated difference exceeding a value representative of equipment capacity. Number display could be toggled via another button.
Figure 34: Mass Balance Indicators
Figure 35: The ISOM unit graphic. This image is from the CSB’s Final Report on the 2005 BP Texas City Explosion and Fire.
The Chemical Safety and Hazard Investigation Board’s report on this accident is recommended reading for everyone in the process industry. The CSB indicated a contributing factor to the accident was the graphic depicting the ISOM unit. The flow out of the splitter was shown, but the flow in was shown on another graphic. No balance computation or comparison was made. This graphic is unfortunately typical – being little more than a segment of a P&ID with “live values” sprinkled on it. There are no trends and no condition indicators. Tagnames clutter up the screen. Color is used inconsistently. There are several other poor practices. The graphic obviously did not provide good situation awareness to the operator.