It is necessary to create a comprehensive, detailed guideline outlining the principles to be followed in designing a High Performance HMI. Such a document must meet the needs of different roles, has several important components, and a variety of uses.
Ideally the contents of the document would be treated as a mandatory standard. In most companies, there is such a large investment in traditional displays, the transformation to High Performance HMIs must be phased in over time and overcome much operational inertia.
A First Principle: Users of HMIs
One DCS manufacturer gives the following poor advice in their user manual for building displays.
“A (graphics design) hierarchy should suit the needs of various users, including managers, MIS groups, engineers, supervisors, and operators.”
This is bad advice because the primary purpose of the HMI is to exist for the use of the operator. While other roles and functions have interest in the data displayed, the operating displays should not be designed for them and proper design should not be compromised based on the needs of other roles. The operator uses the HMI continuously as the main tool for accomplishing their job – the monitoring and control of production. Use by other roles is significantly less frequent and definitely less important.
We have often seen DCS alarms configured to provide an event record for other functional groups than the operator. This is a misuse and abuse of the alarm system, but is done because the alarm system is easy to use for such tasks. Similarly, DCS graphic displays are easy to use (and abuse) to satisfy the needs of other groups and this can result in displays not optimum for use by the operator in actually controlling the process. There are many other and more proper methods to provide real-time process information to managers and other groups.
As another example, the maintenance function may use the displays in troubleshooting and instrument repair. They are less familiar with the process, but the displays should not be designed to enhance maintenance’s process understanding at the expense of the most effective display practices for the operator.
Engineers and managers must also monitor how the process is running. As will be later discussed, a properly designed Process Overview Display summarizes the operation relative to several Key Performance Indicators.
The HMI Philosophy Document and Style Guide – Overview
The principles embodied in a High Performance HMI are communicated in the Philosophy document. The HMI Philosophy document is intended to be generic and apply to multiple types of DCSs. Although several different DCS systems may be in use at a single site (or even in a single control room), it is desirable to make the HMI similar on them all.
There are aspects of an HMI which are very specific to the abilities and paradigms embedded in a particular DCS. The HMI Style Guide is a detailed document specific to a particular type of DCS. It covers the exact methodologies by which the principles contained in the High Performance HMI Philosophy are embodied within the capabilities of the subject DCS. Separate Style Guide sections are needed for each type of DCS.
It is not recommended for a single operator to use multiple types of DCS systems. However, a site’s evolution and capital constraints may have resulted in this situation. In such cases, the HMI designer should bring commonality to the systems to minimize confusion; this scenario is a high risk for human error.
The combination of the HMI Philosophy and Style Guide should embody all of the principles contained in this book. Full examples of the Table of Contents of both a High Performance HMI Philosophy Document and a Style Guide are shown in Appendix 1.
Purpose and Use of a High Performance HMI Philosophy Document
Simply put, the HMI Philosophy document covers how to properly create a High Performance HMI. It is a guide to doing it right. Without such guidance, engineers and operators with the best of intentions will do whatever is thought best and expedient at the time. It will be based on whatever knowledge (good or bad) those involved have picked up over the years. The results will typically be the poor HMIs prevalent throughout industry.
The philosophy document should cover the life cycle of the HMI, including design, implementation, performance monitoring, ongoing modification, and management of change. It is for both in-house use and for the use of contractors hired to work on the system.
Development of a High Performance HMI Philosophy Document
Development of an HMI Philosophy should follow a proper process, particularly if the desire is to overhaul an existing HMI. There will be a tremendous amount of resistance to changing the current HMI. You cannot expect to just hand out this book and say, “This is how we will do our HMI.”
The involvement and buy-in of management, operations technical staff, and operators themselves is needed to develop the Philosophy which will result in the successful adoption of a High Performance HMI. Without this involvement, the change may well be doomed from the start.
HMI Style Guides
The style guide is a highly detailed document. All of the proper principles for HMI design are used in developing the style guide. All aspects of display design are covered – layout, hierarchy, backgrounds, lines, text, objects, trends, navigation, and so forth. Since the style guide is specific to a certain DCS, it specifically documents the exact methods by which proper HMI principles are executed given the DCS capabilities and limitations.
HMI Objects and Object Libraries
The style guide has two major components:
Text descriptions and documentation
Software code and behavior documentation for all objects
The style guide will depict and document the various screen elements to be used in creating displays. As an adjunct, the actual source code and objects themselves are part of a DCS-specific Object Library saved in the software code format of the DCS. Standardized elements are created with specific functionality and included in this library. From this library, the elements are chosen and used in the displays.
It is essential to perform proper Management-of-Change practices on the library elements themselves and their documentation. The elements should not be individually modified in the process of being incorporated in individual displays. This is because it may become desirable to make an alteration in a particular library element and then push out the altered version to all of the displays using that element.
Make sure to create offsite backups. There are horror stories about lost HMI source code.