Standardizing the Operator Interface
The sources of the problems that thrust Pennsylvania's Three Mile Island nuclear power plant into the limelight in 1979 were undoubtedly many, but some would argue that the root cause of that unfortunate incident was that operators, confronted with such a bewildering array of information, could find no clues in the display to tell them what had gone wrong…or what to do about it.
The sources of the problems that thrust Pennsylvania's Three Mile Island nuclear power plant into the limelight in 1979 were undoubtedly many, but some would argue that the root cause of that unfortunate incident was that operators, confronted with such a bewildering array of information, could find no clues in the display to tell them what had gone wrong…or what to do about it. Some would also claim that the chemical disaster in Bhopal, India, five years later was affected by poor decisions made for the same reasons. An operator was supposed to do something, but the design of the display didn't make it easy to determine what.
From disasters such as these, coupled with the growing number and increasing complexity of applications, rapidly advancing technologies, and the globalization of manufacturing, have come the desire, need, and demand to standardize the HMI. As Jay Jeffreys, marketing director for third-party programs, Wonderware, a business unit of Invensys Systems Inc., puts it, “We need a means of simplifying the presentation of data so that a human can actually see and understand what's important, and respond to it in a timely fashion.”
Finding the “means” of standardizing the human-machine interface (HMI) has been a long process, evolving from a few false starts to the present move to bring commonality and consistency to the display through a formal standard, ISA SP101, Human-Machine Interfaces. (See “SP101: Human-machine interfaces” for more on the ISA [Instrumentation, Systems, and Automation Society] standard.)
An historical perspective
A number of events over the last few years have brought industry to the point of seeking HMI standards. In the mid-1980s, ISA developed SP5.5, Graphical symbols for process displays, which focused on instrumentation symbols for process drawings. The standard, developed when information was presented in text in black and white under DOS, is, of course, no longer current with today's process display technology.
Another undertaking in the 1980s, ISA-SP77, Fossil fuel plants, included a subcommittee called SP77.60, Human-machine interface, aimed at fossil fuel power plants. The work never reached standard status, however, and became instead a technical report of recommendations. Now, as SP101 develops, the ISA committee is reviewing what has gone before while seeking to embrace today's new technologies and circumstances.
Joe Bingham, chairman of the ISA-SP101 standards committee (and also president of AES Automation) points out that the committee is “working hard to avoid reinventing the proverbial wheel. We don't want to overlap other standards,” he notes. “For example, we looked at ISA-SP18 [Instrument signals and alarms] on alarm events and decided it was sufficient to say, 'follow SP18.' We'll pull that information into our standard rather than redo what's already been done.”
HMI standardization is also influenced by standards that touch other aspects of automation and control. Though related only indirectly, the evolution of fieldbus technology has likely been a major factor in launching the present standardization effort. Jay Coughlin, manager, HMI products, Siemens Energy & Automation elaborates: “First we had networks providing ways to accommodate devices from any and all vendors. Then came OPC, along with software packages with a common methodology for communicating with each other. Now we're seeing EDDL [electronic device description language] develop.”
It was logical, Coughlin continues, at this point, that consistency and commonality, and the resulting efficiency they bring, should extend to the display. The global nature of business today requires it. “Things just aren't simple anymore,” adds Wonderware's Jeffreys. “When you're controlling a dangerous operation these days, you're probably not looking at a bank of lights and switches and meters; you're probably looking at a computer display.”
Few quarrel with the concept of HMI standardization, which is expected to concentrate on screen configuration and design. Standards are seen as beneficial, if not critical, especially in today's mobile society. Most agree efficiency is probably standardization's greatest advantage. Consistent screen formats make design and use simpler and safer.
It's a good thing
“The industry should have had a standard years ago,” says chairman Bingham. Standardization would bring consistency to screen design and configuration that would facilitate training, he notes, adding that an operator moving from one facility to another today would likely find information presented in different ways, increasing ramp-up time and the need for training. Standardization would minimize, if not eliminate, this problem, says Bingham.
He explains that the intent of standardization is not to ask anyone to redesign products to meet a standard. “We're trying to stay software independent,” he says. “We're working on an exclusion list. We've already established that the standard will not cover cell phones, light boxes (analog panels), chart recorders, watches, or anything with a resolution less than 320 x 240 pixels. In addition, we specified an HMI must have a minimum number (64) of colors. Such determinations will give us focus.”
HMI standards or guidelines are definitely a good idea, concurs Roy Tanner, systems marketing manager, ABB Inc., but believes it will be challenging to determine the scope to which they reach. He says, “We have produced guidelines, but these sometimes aren't followed because customers have their own standards or want a specific look and feel due to previous/existing systems; or because different regions and industries have their own requirements and guidelines.”
Any standard or committee that “brings vendors together to make it simpler for the end-user to configure a system is a good thing,” says Siemens' Coughlin. “End-users, integrators, and vendors all need to [and are being asked to] provide input into a standard, which will give vendors a framework around which to build products. The primary advantage will be HMIs with a similar look and feel regardless of who is supplying the system. Navigation will be more efficient, changes will be easier to make.”
John Roberts, distribution and sales manager, B&R Industrial Automation, also calls standardizing HMIs “a good idea,” but notes that HMIs are used on such a variety of machines in such a variety of industries that it may be difficult to develop something that cuts across all areas. He identifies transportability, continuity, portability as among the benefits of standardization, but says that it “will, out of necessity, have limitations. A machine used for an industrial laundry is totally different than an HMI on a medical scanning device.”
Rami Al-Ashqar, product manager, electric drives and controls, Bosch Rexroth, has a similar perspective. He anticipates reaction to HMI standardization will vary by industry, predicting, “automotive manufacturers welcome standards because they demand consistency. When we work with automotive applications, we see requests for regularity and repeatability, for the same buttons, the same screens every time. Operators know how their screens operate and they want to keep it that way. But in, say, printing and packaging, applications are more innovative; they need to be able to accommodate graphics, recipes, ActiveX controls. Standardization may cause some difficulties there.”
There are many good reasons for HMI standards, agrees Tim Donaldson, director of marketing at Iconics. “There are already good screen design practices to follow, but many elements are coming together at this point.”
Standards, says Donaldson, would give system integrators a common foundation for their systems and ease the learning curve. “A standard would certainly make it easier to move from one package or system to another. Common elements, common symbol libraries, common colors all minimize the chance for misunderstanding.” However, he warns, placement of elements on a screen to achieve that common look also needs to leave room for creativity and customization.
Donaldson says navigation consistency would help. “One approach might be to place certain information in the same place so that operators would always know where to look for it. A standard might specify placing alarming across the bottom and navigation buttons across the top; for example: always require a double click in the top left hand corner when drilling down through tank levels. Microsoft Windows' screens have standardized title bars. If you write a Windows application, it must follow Windows applications specifications. An HMI specification might set down guidelines in similar fashion.”
Standards should address the way screens look and feel, not the tools with which they are built, adds Bosch-Rexroths's Al-Ashqar. “Screen layout and the methodology of interacting with those screens are the key areas,” he says.
“Here's an example: An HMI display shows a parameter by bringing up a box into which the operator must type a value. Some systems provide the upper and lower limits of what that value needs to be; others leave it blank to accept any number. Some leave it as an option, allowing the person programming or configuring the system to choose how to show it. I think always showing the limits just makes good sense. A standard that requires a dialogue box to always show upper and lower limits or lowest and highest values would by a good idea,” Al-Ashqar says.
Icons are an area that standardization might be well advised to target, suggests Roberts of B&R Industrial Automation. “Europe uses icons instead of text in many places,” he says. “A standard set of icons would be helpful. So many companies are global. Similarly, a standard on how alarms are reported would probably be helpful. However, a user interface is typically a personal thing. There are limits to what you can standardize. You have to leave flexibility to do the special things your machine needs to do.”
Becoming more of an artist
HMIs need to deal with many functions, from the clear, consistent presentation of information to the management of alarms to the exchange of data between the plant floor and the enterprise. But what HMI designers ought to be concentrating on, says Wonderware's Jeffreys, are the tools that “let a human assimilate and act on the huge burst of information that's available now from the shop floor.” To do that effectively, “the HMI designer needs to be more of an artist, and less of an engineer.”
Perhaps the need for and benefit of HMI standards are best summarized in this example from Jeffreys: “A while back, I worked with a SCADA system. It was custom developed. We had done a number of installations in the pipeline industry before getting a contract from a utility system to monitor a substation.
“We discovered a fundamental difference between those two applications. To a pipeline or chemical engineer, if something on a display is red, it is turned off, while something colored green is running. But to a power engineer, something colored red is energized. It is hot! Don't touch it! If it's green, it's off and safe. At that time, we had hard-coded colors into the display objects. It was a rude surprise. With no standardization, there was no way to go from chemical application to power application without modification.”
There should be. There needs to be. And what more convincing argument for HMI standardization can there be?
ISA-SP101: Human-machine interfaces
ISA-SP101, Human-machine interfaces, is a work-in-progress. As with all ISA committees, its efforts may culminate in a technical report, recommended practice, or full-blown standard. Or, says, Joe Bingham, committee chairman, “we may create all three documents.” The process typically takes about 3 years.
Work of this committee got underway last year, with an informational meeting at the 2005 ISA Expo in Chicago. The first formal meeting followed in January 2006 in Orlando. “We met about 5 hours and created two sentences,” recalls Bingham, “and felt we'd made significant progress.”
Through conference calls and Web-based exchanges, the committee has developed a purpose and a scope:
Purpose: ISA-SP101 defines the requirements for the evaluation, design, development, implementation, and maintenance of efficient, effective, user-friendly HMIs.
Scope: ISA-SP101 establishes HMI design criteria for industrial control systems, including:
• Information display;
• Process visualization;
• User interaction;
• Performance; and
• Documentation and training.
The committee is seeking feedback from a balance of end-users, system integrators, and vendors. Anyone with an interest in the topic may become an “information member.” The committee will next meet face-to-face at ISA Expo 2006 in Houston in October, when the focus will be on definitions.
Says Bingham: “We need to define terms upfront. If we have a strong list of definitions, we'll eliminate a lot of ambiguity.” Definitions under development now include HMI, historian, event, alarm, display, process visualization, human factors, screen density, trending, audio, PDA, pixel, resolution, start, stop, and tactile feedback.
For more on the standard, visit the ISA Website firstname.lastname@example.org ISA staff contact Loanna Overcash email@example.com.
The art of HMI design
For more on the concept of the HMI designer/developer as artist, Envisioning Information by Edward R. Tufte supplies practical advice about how to explain complex material by visual means and present information so that a graphical picture is formed. Some 400 illustrations, including examples of how not to use color, are provided. (Published by Graphics Press, 1990, $48; ISBN# 0961392118. Learn more at
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.