Interested in linking to "User interfaces should empower operators"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
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:
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:
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.
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.
ControlGlobal.com is exclusively dedicated to the global process automation market. We report on developing industry trends, illustrate successful industry applications, and update the basic skills and knowledge base that provide the profession's foundation.