User interfaces should empower operators

By Wayne Labs, Contributing Editor

THE 1994 EXPLOSION and fires at the Texaco Milford Haven Refinery (U.K.) injured 26 people and caused around £48 million damage as well as significant production loss. The government investigation found these key user interface (UI) problems:

• There were too many alarms and they were poorly prioritized.
• The control room displays did not help the operators understand what was happening.
• There had been inadequate training for dealing with a stressful and sustained plant upset.

In the March 23, 2005, Texas City, TX BP Amoco Refinery explosion, 15 workers were killed and 170 injured when a column was overfilled, overheated, and overpressurized on startup. In its self-conducted 47-pp “Fatal Accident Investigation Report,” BP Amoco suggested several proposals for corrective actions. These included:

• Conducting an independent third-party study of existing alarm systems to identify deficiencies and make improvements
• Installing a high-level alarm on the column base level and a flow indication on the column overhead relief line
• Reviewing the engineering structure to simplify the interface between Engineering and Operations
• Establishing the sanctity of the control room (i.e., removing distractions.), and reviewing staffing procedures.

The Holistic User Interface
The operator interface played a major role in both of these disasters. Ian Nimmo, P.E. IEng MIIE (CEI), and president, User Centered Design Services LLC, points out three problems that demand industry-wide attention. First, the quantity of system alarms overpowers the operator with unimportant information. Second, the GUI design has its own issues. The over-designed “Christmas Tree” HMI screen with flashing lights and zillions of colors needs simplification while old-style DCS text-based readouts need to be changed to easy-to-see graphical objects such as meters and strip charts. Third, human factors such as environment, length of shift and distraction levels must be reconsidered from a safety point of view.

Alarms
Dal Vernon Reising, principal research scientist, Honeywell ACS, asks, “What would your day be like if you got one email per minute?” Says Reising, “In studies the ASM Consortium conducted among its members, several manufacturers reported seven to eight hours each month where operators received 100 or more alarms in a 10 minute period.” And yet the Engineering Equipment & Materials Users’ Association (EEMUA) recommends that operators handle no more than one alarm every 10 minutes during normal operation, and not more than ten alarms in the first ten minutes following a major plant upset. Says Yokogawa’s productivity solutions consultant, Fred Woolfrey, “Even the best operator in the world, who knows the software and the process, can’t function with an alarm every minute.”

Nimmo says that engineers often design systems with unnecessary alarms because building alarms is easy and free. Today’s DCS offers more than 7,000 alarms, most of which can be built into the software for free without having to install an additional sensor or transmitter.

What can be done to empower the operator—rather than overpower him? Many vendors realize this is a major issue and are coming up with plans of attack. One such tool is Alarm Hiding, which locates and filters the alarm, based on the alarm’s condition. According to Roy Tanner, ABB System 800xA manager, the alarm is hidden until it’s absolutely necessary to reveal it.

This is not rocket science for machine designers, and according to Rockwell Automation IPB marketing programs manager, Don Steffens, alarm management should be built into the system design, starting at the controller level. “Alarms for missing power should be suppressed in the engineering design. The same is true for one alarm that may trigger 100 more alarms—the ‘waterfall effect’,” Steffens said. The operator only needs to see the initial cause—not the additional 100 alarms. According to Renée Brandt, product marketing manager for Visualization Products, Wonderware, large numbers of alarm bursts can be stored, historized, and analyzed—allowing the operator to determine which alarms need the quickest response. Alarm trees allow the grouping of alarms by hierarchy to discover the critical ones. Pareto charts can also be used to determine which alarms are frequent and which need greater attention.

Two additional problems with alarms can be caused by operator perception—both of which are dangerous. First is ignoring a crucial alarm because it only shows up once or twice, is barely noticed, and doesn’t seem important among several other alarms (this was considered a major issue in the Texaco disaster.) The second is not believing an important alarm because the instrument reading seems too far off to be at all credible. Says Bob Shepard, Invensys Process Systems, “The problem at BP stems from what I call ‘cognitive lockup.’ At BP Amoco, six operators were so concerned with how to get rid of all the material filling up the column that they missed the bigger picture.”

Get the UI right
Bad UI design can exacerbate the alarm problem. When a multitude of colors, animation, and graphical objects became available for the PC, many UI designers likewise got carried away. Part of the problem, according to Reising, is that when the tools became available, engineers with little or no training in interface design developed the user interface. According to Shepard, a well-designed graphics screen should allow the operator to comprehend the status of the plant. Typically, humans can absorb seven chunks of data at a time and, if presented with more, will miss it. The way to sensible screens, or a human-centered interface, is to use more static displays that employ animation and flashing colors only when problems arise. Brandt suggests popping critical alarms up on the screen and making them more visible with color or blinking lights.  Shepard advises using colors to suggest alarm priority. One point to remember about the use of colors, cautions National Instruments’ software group manager, Robert McManamy, is that certain colors may have a specific connotation in the U.S., but different connotations in other cultures. He also suggests avoiding the use of multimedia if it means the operator must use his hands to control the playback.

Traditional DCS screens were typically black with a plant layout on the faceplate. Process variables were often indicated by changing text values. According to Reising, the trend is away from black screens to very light backgrounds and gray schemes for the processing equipment Color is reserved for critical changing information and alarms. The use of eight primary colors, yoked navigation, embedded alarm indications and tabs to navigate among windows makes it easier for operators to find what they need. Trends and multiple windows also make information more accessible and understandable. The use of “meters,” found in PC-based UIs for some time, is becoming the norm for the DCS to show live data. Operators find it easier to follow and remember the trend shown by a meter or graph than to remember numbers.

Another good design practice, according to Iconics director of marketing Tim Donaldson, is to build the screen in layers. Building in layers allows operators to turn layers on and off individually; for example, an overview layer for several tanks, another layer for values, a layer for level, and a layer for alarms. Some other necessities for building an effective user interface, according to Roy Kok, GE Fanuc manager of Proficy Software, are the ability to reuse graphic elements, higher level interfaces (e.g., calendar controls, paging interfaces, alarm and event management), scripting, real-time databases, and math and logic functionality.

Reuse of modules as accumulated by a DCS vendor in a public library speeds up the design process and produces better user interfaces for operators and technicians. Ian Pickett, project manager at Lever Fabergé in Warrington, U.K. recently updated the process controls and user interfaces for its Persil detergent product lines. The update included slurry, tower, and raw materials areas of the plant. Emerson’s Project Builder Library is a library of standard modules and tools for the DeltaV system and includes modules from more than 200 projects. According to Picket, the use of the tools cut design and implementation time significantly.

Can the benefits be quantified?
According to Reising, one member company of the ASM Consortium conducted tests using human-centered design methodologies and found operators could complete task scenarios 41% faster than using older UI designs. Operators also dealt with failures in 96% of the cases (a 26% improvement) and recognized the presence of the failure before the first process alarm in 48% of the cases (a 38% improvement).

Predicting time to fail might head off a catastrophe. Current software can predict the number of operating hours before a warning status alarm is triggered.

Human factors
According to Bob Shepard, the human factors (HF) approach to design is to reduce human error (which accounts for 80% of industrial accidents) by changing the workplace—and sometimes worker behavior. In the early DCS days when black screens were used, lights were dimmed to cut the glare from the screens. With that setup, the operators needed frequent breaks to avoid drowsiness. Lighting is less of a problem today because LCD and plasma displays work well in high-ambient lighting conditions. But operators still need a break and, to allow for this, some companies have put in separate exercise and nap rooms.

Fresh air at the right humidity level (50%), lack of noise, and proper traffic flow in the control room are important. All too often, says Nimmo, architects forget the control room’s purpose and instead they design “art for art’s sake.” In one instance, Nimmo got a domed ceiling with operators facing each other at the perimeter, producing a real cacophony of noise, perfectly amplified by the dome.

Long shifts are becoming the norm in the process industries where it’s not uncommon for an operator to work 18-hr shifts. One argument for the long shift is that there are fewer turnovers and, hence, less chance for miscommunication among operators, but workloading and scheduling remain real problems. Producers, says Nimmo, should look at the complexities of their operation, the interfaces between streams, and the DCS (alarms, loops, operator demands) very carefully before arriving at a fixed manning index.

According to Shepard, operators are being saddled with more responsibility—not less. While the number of control points has not changed that much, what has changed is the size of the equipment and the revenue size of the material flowing through the equipment. In the 1970s, the operator typically had control of 30-60 control valves with one process unit. Today the average operator has control of about 175 valves through a DCS. This change in job loading is equivalent to reducing manning requirements for the console-operator by 85 percent.

According to Nimmo, there are major staffing problems in the industry. If this continues, the HF aspect of the user interface will be the most crucial part of the equation.

1. Define Information Requirements—Understand the system, interview operators.
2. Create a Graphics Style Guide—Define UI, ensure consistency in graphics.
3. Create a Graphic Object Library—Simplify the design task.
4. Create Display Sketches—Maximize graphics to ensure pattern matches.
5. Conduct Operations Design Review—Review design sketches for validity.
6. Conduct Implementation Design Review—Minimize costs and rework of graphics.
7. Revise and Document Display Design—Redesign issues should be handled now.
8. Conduct Quality Control of Implementation—Test with real operators.
9. Evaluate Usability Using Operators in a Simulation/scenario-based approach.
10. Enhance Display Design—Make minor adjustments, complete documentation.

Source: Ian Nimmo