HMIs evolve in process control

ControlGlobal.com

New HMI technology is putting a whole new (inter)face on how operators view control systems information, while at the same time driving human error out of systems and improving safe work practices.

By Ian Nimmo, president, User Centered Design Services LLC

THE PROCESS control industry’s understanding of human machine interfaces (HMI) has evolved. In the early days of automation, the pneumatic panel became the first process industry HMI. These panels (See Figure 1 below) were well planned and broken down into task-specific sections, optimizing the panel operator’s performance. Without incorporating task analysis and forethought into the optimal instrument layout, the panel operator would have had to run backward and forward and up and down the panel.

Early panels allowed operators to manage specific equipment, such as a boiler or a furnace, from one position with clear understanding and separation of controls. For example, a fuel gas system and boiler feed water were grouped into a logical concentration. The ignition system also was in a logical location with appropriate alarms and interlock mechanisms within easy reach. These panels often had an overview mimic of the process, which was very comprehensive, but often out of date.

FIGURE 1: TRADITIONAL PANEL

Early control panels only indicated equipment status (lights at left), annunciated alarms (two-deck component at right), displayed process variables (windows at center), and relied on human perception (operator in foreground).

In the 1970s, this panel was replaced with an early DCS which didn’t have an overview feature, and only allowed the operator access to a group of eight controllers (See Figure 2 below). This initial DCS had many pages of these groups, and operators managed to memorize which controller was on which page. Less familiar operators relied on special keyboards to navigate to relevant groups. Plus alarms within a group caused the keyboard button to annunciate the alarm.

Each controller was a software representation of the pneumatic or electronic equivalent controller located on the panel. The group was configured based on layouts on the panel, and no new task analysis was done. So, sometimes due to the limit of only eight controllers per page, a necessary grouping was lost, and operators had to navigate other pages to make appropriate moves to resolve an abnormal condition. Though operators lost the trend that was with the controller, they could navigate to a detail display to retrieve this information. This was only done during the diagnostic process, so normal operation lost a valuable insight to changing variables and direction of change. The big picture provided by the mimic panel soon became outdated, leaving operators with only a keyhole view to the process. The only overview the system provided was an Area and Unit overview display, which provided a summary of the group display.

The discipline of task analysis was also lost in this transition, and the operator became adept at finding information, but often suffered from tunnel vision. Hence, the need for additional alarms was conceived, and DCS vendors applied software capability to the solution. Though the system had some minimal trending provision, it was difficult to use and not always user friendly, so operators became reluctant to use the trending system. Some managers tried to reuse some independent trending equipment, but because there was no dedicated person to service the trending equipment, they too became superfluous.

FIGURE 2: DCS: THE EARLY YEARS

Originally, DCSs didn’t have an overview feature, and only gave operators access to a group of eight controllers.

The next DCSs came with powerful capabilities, and allowed any single point the ability to configure multiple alarms per controller.  Unfortunately, without any disciple or management of change, the plants’ alarms went from 75 hardwired alarms to 24,000 alarms with some duplication. A single event could initiate several of these functions such as level, plus rate of change, and sometimes bad process variable as the transmitter went out of range.

This generation of DCSs (See Figure 3 below) also provided simple graphical representations of the process. These early graphics were crude and fairly low resolution, and their design was based on simple segregation of the plant P&ID. This was the control engineers’ perception of the process, and how they related to it. Before long, operators complained about the graphic or schematic designs because they didn’t reinforce the operator’s mental model of the plant, and the loss of task organization needed the operator to redesign the graphics.

	FIGURE 3: STICK FIGURES
	Initial, DCS-based process representation graphics were crude and fairly low resolution, and their design was based on simple segregation of the plant P&ID.

The redesigned graphics improved, but were still problematic because they went from a logical interpretation of the P&ID to an ergonomist’s worst nightmare. They had major human-factor issues, too many colors, and multiple uses of color. Rather than reserving colors like red and yellow purely for alarms, all color in these graphics was high intensive. The objects had unnecessary detail; object sizes and position on layout weren’t consistent with relative importance; the direction of flow was inconsistent for feeds and products; symbols and lines were poorly implemented; text and numbers were small; and fonts were difficult to read. Numeric format also was difficult to read, some variables had inappropriate levels of detail, and engineering units were inconsistently applied, especially as a space-saving exercise to cram more information on the screens.