HMI / Alarm Management

Design alarms and HMI for smooth operations

Standards are necessary, but not sufficient to achieve best practices and situational awareness.

By Paul Studebaker, editor in chief, Control

CONNECT 2016

The control system human-machine interface (HMI) has come a long way, from the banks of dials and meters of the 1960s through the full-color, three-dimensional moving graphics of the 1990s to today’s human factors engineering-based rules to support situational awareness. Those rules have been encoded in standards and embedded in software libraries and style guides so HMI developers no longer need to invent their own. But it’s not always clear how to use them.

“Whether they’re from the ISA, ISO or API, industrial standards are consensus minimums,” said Bridget Fitzpatrick, management and human factors practice lead, Wood Group Mustang, to attendees of her session, “HMI and Alarm Management” at the Schneider Electric CONNECT 2016 event this week in New Orleans. “The hardest thing for an engineer is writing about the bare minimum, beating the best practices out of the standards.”

Fitzpatrick is active in ISA18 (alarm management) and ISA101 (HMI) standards and practices committees, and is managing director (ISA18 committee) on the ISA Standards and Practices Board. “A committee may have 200 people, and the result is standards that are not perfect, not best practices, but a good starting point,” she said. “They let you set a framework for managing scope and keep you out of trouble. The standards committees also offer recommended practices and technical reports, and these can lead you to best practices.”

The alarm management standard ISA18.2 was published in 2009, and became the basis for the international standard IEC 62682 in 2015. “There is a new version of 18.2 in 2016 as a five-year revalidation, and we have a number of technical reports coming this year from the working groups,” Fitzpatrick said. Evolving requirements for control systems have resulted in new functionality, including shelving and designed suppression in many systems.

In 2017, IEC 62682 maintenance will begin. “All the differences between ANSI/ISA18.2-2016 and IEC 62682-2014 will be submitted as comments as we endeavor to keep the two standards, managed through two different organizations, closely aligned,” she said. Meanwhile, the ISA18.2 committee is working on a technical report on packaged systems alarms and evaluating a technical report on events and alerts, “conditions that do not make the cut as alarms,” she added. EEMUA’s third edition includes the alarm management lifecycle from ISA18-2, so there is global convergence on alarm management.

In the plant, alarm management should “start with a philosophy,” Fitzpatrick said. “Everybody has an opinion. Have the discussion, have the arguments and write that philosophy.” Set good guidelines to reduce the time required, and define work practices so things go smoothly. Run tests to find and remove nuisance alarms, and demo the alarms to show how they work. “Check that alarms get the response you want, that you have a system that’s used and alarms are not ignored,” she said. In the end, remember: “Operations owns alarm management—it’s an operations tool.”

To be sure the system is effective, “Have periodic ‘cold-eyes’ audits by someone who is not involved,” Fitzpatrick added. “A good alarm system will give you better interaction with government inspectors and insurers, and may help reduce your rates. And a calm, well-ordered workplace will help you attract and keep skilled operators.”

HMI needs its own set of rules

“Having system standards for HMI is an important step that many people miss,” Fitzpatrick said. “Have a written philosophy, and a style guide.” ISA101 is the lifecycle standard, and the ISA101 committee currently has three working groups: WG1 is writing a technical report on philosophy and style guides; WG2 is writing on usability and performance, and WG3 is writing on mobile devices. “API 1165 has wonderful words, but really bad pictures. It’s being revised for 2017,” she said.

“It’s good to remember that field control has evolved to help us make things faster and better. We want stability and extended times between shutdowns,” Fitzpatrick said. “We need to design HMI to support operators through the whole range, from best operation through ‘The ESD failed and everything is on fire.’”

Consider what the operator needs, which is what is useful. “The ability to do stupid computer tricks is a lever, but it has to be used to help us be agile and competitive, to help the operator be the manager of the process,” Fitzpatrick said.

“An HMI starts as a blank canvas—you can draw anything you like. And that’s not necessarily a good thing,” added Grant Le Sueur, senior director, offer management, Schneider Electric. The company partnered with Acuity and references ASM style guidelines to produce standard symbol libraries users can draw on to create consistent, compliant HMIs. Instead of hundreds of versions of a common element (such as a valve with different options in various positions), a single symbol can be configured and used in all HMIs across a facility or around the world. A change to a particular symbol can be propagated to all its instances.

Style guides that govern placement and colors also provide consistency, as well as programming support for situational awareness, where operators can see at a glance how the plant is behaving, and drill down into any abnormalities. (For more information, see the white paper, “Situational Awareness and Control HMI for Operators” here).

Individual companies such as Shell or ExxonMobil can customize their libraries and create their own styles, use them across all their sites and share them so EPCs and SIs can supply compliant projects, making engineers more efficient and saving the cost of creating separate specifications and documentation.

Operators can move from unit to unit or relocate to another plant without retraining, and maintain the response speed, safety and efficiency that comes with reflexive understanding of what the HMI is telling them, and how to react.

Make your style guide into a living document. “Don’t use it once for the initial design and then ignore it through the lifecycle,” said Fitzpatrick. “If you make an exception, go back and write it into the rules.”

The proof is in the plant

It’s valuable to be on good terms with your operators. “Have a relationship where they’ll tell you if something doesn’t work,” Fitzpatrick said. “It’s painful to throw away something you created, that you put a lot of work into, but, if it’s wrong, it has to go.”

Give them what they need. “If they have a variance in how you do something that matters, put it in the HMI,” she said. “Give them real-time support.” During an emergency, this is not, “Read the procedures.” If recovering from a utility loss means running around figuring out lineups, get them into the system. If you have expert systems, integrate them so operations can learn in real time.

A well-designed HMI can work wonders. “For a while, my responsibilities included energy optimization of a steam system, and my salary depended on the energy savings,” Fitzpatrick said. “I put consumption in the corner of the screen in real-time dollars to highlight wasteful practices, and the shifts started to compete to see who could use the least energy. I made money, but the operators took over and my position was eliminated.”

In another case, the procedure for trip check on a boiler was not being followed. “It needed to be done perfectly, so I automated it,” she said.

In the extreme case, for upset operations, “it’s important for operators to know the normal operating envelope and be able to immediately understand the cause and effect of a failure so they can address it,” Fitzpatrick said. “Visually highlight what didn’t work, and why. Think about catastrophic loss—an ESD failure—and what the operators need to know to minimize consequences or even to save their lives. Tell them when to leave, and which way to run.”

CONNECT READ MORE2