Regardless of your starting point for a human-machine interface (HMI) project, we recommend following the ISA-101 Lifecycle Model. Every project should be based on the "HMI Philosophy and Style Guide" document. The role of the philosophy document is to confirm what good looks like and make sure that the process control operator's desktop has consistent and common HMIs across all platforms and manufacturers' equipment in use (Figure 1).
The ISA-101 Lifecycle Model
The role of the style guide is to interpret the philosophy in the language of a given vendor, such as Honeywell Experion PKS or Emerson Delta V, etc. The style guide will have a lot of commonality with the philosophy, but the style guide will have vendor-specific language on template windows and color selection.
Hence, it is extremely important to the success of a project that the philosophy document addresses many of the problems described in our August column ("What Is High-Performance HMI?"). I have many customers who claim to have a philosophy document for their HMI that is about six pages long.
Our philosophy document spends more than six pages just talking about color, and it's more than 75 pages and covers:
- Display design—human factors engineering principles and functional requirements,
- Display hierarchy,
- HMI elements,
- Alarm depiction and alarm management, which is harmonized with the alarm management philosophy document,
- Guidance on the HMI design process,
- Purpose and use of the HMI style guide and toolkit or object library,
- How to measure HMI performance,
- Management of change of HMIs,
- The impact of control rooms on the HMI, and
- Large-screen display considerations.
It is important that the document is good enough to be the rules for an HMI gap analysis, allowing users to compare their HMI graphics against a detailed guideline with easy-to-use key performance indicators (KPIs).
Having a solid foundation to build on is extremely important, and having an enforced policy that ensures compliance is just as important. Many HMI projects start out with good intentions. However, somewhere along the way, they get derailed, and any coding or design principles get lost in the mix of getting the plant working—and the preference is to do it "my way."
The design process should be guided down the path of getting good requirements capture. This can be done by a variety of techniques, the simplest being a very basic task analysis to the more involved hierarchical task analysis (HTA) promoted by the HMI experts and academia.
This is another important step often left out or substituted by just copying P&IDs and sprinkling live data on top. Doing so leads to information and data being distributed over many pages of graphics, and makes a simple adjustment very complex because of the navigation issues. For an operator to adjust four controllers (A, B, C, & D), he or she currently has the navigation nightmare illustrated in Figure 2.
The task analysis should identify the hierarchical information required for each of the displays from Overview, Unit View, Detail View and Diagnostic View. The philosophy and style guide will dictate how the information, based on priority and importance, will be displayed.
The philosophy also dictates how to take advantage of color, brightness, contrast, salience and line thickness, combined with graphical objects designed to transform data into information. In the past, HMI schematics have relied on operators interpreting lots of data and using high levels of cognition to put the data into context.