As a machine builder or process plant designer, the Human Machine Interface for your equipment most likely does not receive as much attention as it should. Typical HMI projects add from 8-12% to the total cost of the machine or process system. (This may run a little higher on a small machine with extensive HMI requirements, or a little lower for a plant wide automation system.)
But the HMI is also the principle point of contact between your equipment and the user. A good HMI design will make your machine seem intuitively easy to operate, while a poor HMI can drive away customers even when the process or machine is based on a sound and innovative concept.
It is the job of the HMI programmer to understand the needs of all the users of the equipment and to make an HMI that will answer all those needs without needlessly complicating the life of the people who use it.
Generally I like to lay out the HMI design in such a way that at least three different classes of user are served:
Operators need ready, intuitive access to the subset of controls that they need to perform normal daily production tasks on the equipment. In general, operators should not have to deal with a lot of data that they do not need to perform their jobs, but detailed data should be available on request when needed for process troubleshooting.
The scope of an operator’s ability to change machine settings is generally limited to prevent unauthorized ‘experimentation’ with process parameters, and to eliminate as much as possible the potential for errors by limiting the number of parameters with which an operator has to deal.
Recipe based systems are the ultimate implementation of this concept. With recipes, operators tell the machine which part or process is being run and the control system uses this selection to choose appropriate process settings from a stored bank of preprogrammed recipes.
The controls accessible to an operator should be intelligent and limited enough that an operator cannot damage the machine or easily ruin the product by making improper control settings.
Supervisors are granted a higher level of control over process parameters and recipes than operators. Generally, access to different features of the control interface is controlled by a password / login procedure.
In many cases separate screens showing more detail information and offering more data entry objects are provided for supervisors, though supervisors can work through the normal operator screens where proper access control has been provided.
Supervisors need to be familiar enough with the machine or process that they will not make selections through the HMI that might damage the product. Generally supervisors are locked out of those control settings that might allow them to damage the machinery itself.
Maintenance people need complete access to the full range of machine controls and data displays. Sometimes maintenance functions require abnormal system operation that, if performed incorrectly, could damage the machine itself or could produce scrap product.
Controls for these functions must be clearly labeled and reserved to only those with the highest level of access. Maintenance screens are generally hidden from operators and supervisors, and a bit of clutter on the screen might be permitted, since these screens are infrequently used.
Some features of a good HMI are common to all classes of user:
Alarms and Error Reporting : When error conditions exist, the operator should be notified promptly by means of a plain language message that appears no matter where in the operator interface the operator is working at the time.
A complete HMI system will provide for maintaining a log of error events showing at least time and nature of error, time error acknowledged, and the time when the error was cleared. The error message should be understandable and should provide guidance for starting the troubleshooting process.
The goal when writing error messages should be to guide the operator to fix the problem without having to call maintenance or a supervisor, and good error messages will take into account the operator’s level of skill and knowledge.
Help files should be provided . Two different types of help files can be provided. In the simplest form of help system, the operator selects help topics from a list provided as part of the HMI and can read those files at any time.
At a minimum, major topics and issues should be addressed in concise, easy to understand documents. Illustrations based on cad drawings or digital photos can be a great aid to understanding. As an extension of this system, we provide the full content of the machine manuals in computer readable form right on the operator interface when the HMI is PC based.
The other kind of help is content addressable pop up help screens. In this case, each error message has an associated ‘help’ button. When an error message appears, the operator can press the help button to see a help screen specifically addressing the topic of the error message. Generally these pop up screens are not viewable until the associated error occurs.
Data Logs: All modern PC based HMI products make provisions for data logging. In many cases use of the data logs will be an integral part of the HMI project, with data being collected for customer reports or for on-screen strip chart displays.
But even if the customer has no data logging requirement, a complete control system design will include provisions for logging key data points which will provide information to support the manufacturer’s service people and the software engineer in their troubleshooting efforts.
A little extra effort at design time spent setting up data logs will generally be rewarded sometime during the life of the machine when those logs are used to help solve a troubleshooting problem.
In the ultimate implementation of a data log system, data is collected and arranged into custom reports which are used by management to evaluate machine and operator performance, by maintenance to schedule preventive or proactive maintenance programs, or by quality control to document compliance with standards and specifications.
Clearly Differentiate Between Readouts and Data Entry Points. Use color to indicate status: Use a systematic approach in the assignments of colors and other features to controls and data readouts so that users will learn to tell at a glance which values they can change (data entry points) and which are reporting actual process values (readouts).
Use the HMI product’s full capabilities to create color coded displays that indicate at a glance whether actual values are within an acceptable range or controls are configured for normal operation. At the same time, resist the temptation to use a lot of different colors just for the sake of doing so.
Your object should at all times to use color to enhance the understandability of the screens, not just for decoration.
Here are some sample HMI screens from a moderately complex electroplating machine with comments to illustrate the discussion above: (used with permission)
Main startup screen. This is the screen that appears at machine startup and is one of the operator’s most frequently used screens. It contains controls from starting and stopping the machine, and status displays to advise the operator of machine status and parts in progress. Buttons at the lower left access other screens.
Only one other screen is frequently used by base level operators. This screen is the one used to select product recipes from a pull down list of preprogrammed recipes.
A machine overview screen contains indicators associated with each process station which show whether a fault exists in that station (red bars) or whether manual overrides are in effect on any controls for that station (yellow bars).
This screen provides access to the detail screens for each station. This image also illustrates the pop up red error message banner which appears on every screen when an unacknowledged error condition occurs.
The station detail screens are seldom used by operators. They provide complete details of all process settings and raw sensor data associated with that process station, plus manual override controls and status displays for each component. Many of these controls are access protected to restrict their use to supervisors and maintenance personnel.
‘Trend’ or strip chart recorder style screens can provide historical process data in an easily interpreted form:
Help screens can be in the form of simple text files or drawings:
Or more elaborate screens with step by step troubleshooting instructions:
Controls and readouts on this maintenance screen are used only by authorized service personnel to adjust some control parameters and to select some abnormal ‘maintenance’ modes of operation which are useful for testing.
Datalogs in their raw form are comma delimited text files (or data entries in the customer’s own ODBC database). They can be opened with Microsoft’s Excel or Access products, or many other database / spreadsheet programs.
This raw data can be formatted by other programs like Microsoft’s Access database tool, Crystal Reports report generator, or others to provide reports that format and present the data in the most usable form.
Credits: falconlabs