This content was written and submitted by the supplier. It has only been modified to comply with this publication’s space and style.
The future of operator interfaces will clearly follow the consumer market with intuitive, interactive help systems using video and animation, and even soon-to-be-introduced industrial HMI touch panels with multi-finger gestures.
However, the industrial present, for the most part, consists of limited freedom of design due to touch screen construction and a range of stop-gap documentation methods due to the relatively high cost and low functionality of both the HMI hardware and software.
As a result, operators try to find work instructions scrolling through a pdf document of the print manual on a 6” screen. Perhaps there are additional photos or even a PowerPoint show. But with a limited Windows™ CE operating system or simply no budget for the machine builder to develop more effective systems, this is too often the reality.
This reality is beginning to change with the introduction of higher performance, lower cost industrial PCs, some benefiting from Intel Atom® processors, others from powerful dual or even quad core Pentium® class processors. It’s no problem for these machines to run Windows™ XP Embedded or even Windows™ 7 and support a full range of graphical tools.
But let’s stand back for a moment. Regardless of how sophisticated or straightforward your help system, the fundamentals don’t change. Here are seven simple rules to make every help system more effective.
True, they’re broken every day. But they shouldn’t be.
If you are involved in the design, sales or support of machinery you can start by writing the seven one-liners on the white board. Assemble your team ask them what these statements mean to them.
If you are a machinery buyer, specifier or maintainer, consider lifting these seven rules word-for-word and adding them to your user requirements specification. That was easy, wasn’t it?
1. The help system should be context sensitive
That is, it should never just be a document to page through. And yet, many help systems are just that. Based on HMI screen content, pressing the ‘help’ button should open the help system to the appropriate information.
One scenario would be, based on the alarm that’s currently active, the help button should open the help system to the appropriate solution tree or procedure to remedy the situation.
The OMAC PackML alarm tags provide an existing means to standardize and organize alarms and response.
Another scenario would be, if no alarms are active, the help system should open up to an overview description of the screen that is currently active.
Every screen must provide clear navigation to the help system. In a potential downtime situation, the operator should not be on the spot to find how to access the help system.
2. It must be multi-lingual
The help system should present information in the language of the operator. In the case where the HMI is multilingual, the help system should automatically select the same language as the machine operating screens. No additional user intervention should be required.
3. Please be concise
Based on the “user class” of the person at the machine, the information presented to the user should be appropriate. Information pertinent to other user classes is a distraction and should not be presented. That is to say, if a user is logged into the HMI as an “operator”. The help system should display only tasks he or she can perform or information pertinent to their duties. Don’t present information on tasks that only a “maintenance” user can perform.
The user class may be interpreted as a security level in some applications.
4. The system should allow help information to appear on multiple display devices
The display devices may be multiple HMIs on the same machine. They may also be different hardware platforms, such as PCs, tablets and smart phones.
Each display device should be capable of navigating the help system independently. Two people navigating through a help system, on separate devices, should not interfere with each other.
Machine mounted display devices should take into consideration the viewing angle of the user. An example of this would be: If an operator is standing at the HMI and the product flow through the machine is left to right, the diagrams on the HMI should depict the machine with product flow left to right. This is a concern when HMIs are located on both sides of a machine and when machines are installed on left and right legs of a line. Mobile display devices present the same concern.
5. It should have the ability to be hosted locally or remotely
A single centralized help system information repository should be maintained. This is to avoid conflicting or incomplete information in disparate systems.
For non-networked environments, the help system should be capable of running ‘stand alone’ on the machine for which it is intended. For networked environments, the system should be capable of being hosted on a central server.
No content changes or application changes should be required to support these two environments.
6. Help system content should be developed utilizing qualified technical writers
Control engineers should not be utilized to develop help system content. Instead, they should be used as a resource to technical writers during system development and testing.
Control system resources used by the Help System should be limited, thus limiting impact on control system performance. This also minimizes chances of a control system change affecting the help system information viability.
7. Help system content must reflect the requirements of the machine’s risk assessment
The risk reduction methods prescribed in the machine’s risk assessment must be described in the help system. If the help system directs the user to perform a task that has particular hazards, care must be taken to indicate those hazards in the help system. This is particularly true when the help system is taking the place of a printed manual.
