Creating an HMI that doesn’t get used

When that new equipment skid or machine comes in, it probably has its own HMI, but that equipment will be controlled from a larger system. What should you want that redundant HMI to do?

By David McCarthy January 3, 2013

Much has been written on how to design intuitive and functional HMIs (human machine interfaces) across a variety of technical and process platforms. But have you ever thought about how to design an HMI that rarely gets used? It happens more often than you might think. You can find these devices tucked away in all sorts of process areas on your plant floor where operators rarely seem to go. Want to know more about design best practices in this specialty area? Here are some things that can help you specify and use those industrial orphans.

Come out, come out, wherever you are

The most common place to find a low-use HMI is in dedicated process equipment subsystems that are integrated into larger plant-wide systems. These are referred to as skidded systems and can be found in many diverse applications such as bioreactors, chemical injection systems, clean-in-place systems, chromatography skids, media/buffer prep systems, waste neutralization systems, pasteurizers, vitamin/mineral injection systems, and much more.

The day-to-day functionality of this equipment is usually controlled elsewhere, as part of a larger DCS or HMI/SCADA system. Given that, why put a local HMI at all in such places? There are lots of reasons, ranging from how these subsystems were constructed and validated, to routine maintenance, and even emergency operation. Let’s take a closer look at each of these use cases to get better insight into the best design criteria.

Use it or lose it

Skidded systems are often assembled and validated independently of the larger system. Initial validation and testing is usually a factory test at the skid manufacturer’s facility. A similar site test is performed when the skid is installed on the plant floor. Depending on the industry and process, these validations might be quite extensive.

A local HMI can facilitate this validation and testing in a variety of ways. During the factory test, it provides a window into the process equipment that might otherwise be difficult to see without the host system. This includes visibility of all instrumentation and equipment status. Usually the first test ensures everything is operating mechanically and electrically as expected. A local HMI can force on or off (with proper security) controlled equipment to confirm everything is working as anticipated. Once installed and running on the plant floor, these same features can provide plant maintenance technicians with the ability to monitor and control the equipment on the local skid if needed.

A local HMI can also facilitate testing of automated sequences and phases on the skid. Local monitoring can provide at-a-glance status of all sensors, control items, sequence, or phase status active on the skid. If desired, a local HMI can also initiate individual control phases and sequences. This provides testing capability without the host system connected, and provides emergency operational service once the skid is installed on the plant floor.

Platform considerations

Now that we have an idea of where we find these HMIs and how they are used, a key design element is to determine the best hardware/software platform to use. You could look to match the host system, or go with something less advanced. There are advantages with each approach.

If matching the host system, the local HMI can be maintained in the same software development platform, which simplifies archiving, version control, and routine maintenance of the system. This also eliminates procurement, maintenance, and training costs associated with multiple development platforms. Standardized hardware further reduces spare parts inventory and carrying costs. Network connection to the local HMI is the same as the rest of the workstations in the host system. If needed, it is generally easy to display host system screen and tag information in the local HMI. If the skid is designed for local maintenance and emergency operations, security is likely more robust with this approach.

A less advanced HMI platform has its own set of advantages. This approach usually has lower upfront hardware and software costs. Programming costs may also be less expensive in this environment. These solutions often have smaller physical fingerprints with regard to control panel real estate. Network connections may match the host system, or employ a simpler direct connection to the skid programmable controller, savings network cabling costs.

Bringing it all together

As we have discussed, local HMIs may be used only for testing, or they may play a longer-term role in the maintenance and emergency operation of their associated equipment. They can be on the same platform as the host system or on a less advanced platform.

If you answer yes to any of these questions, you can probably manage with a less advanced and less expensive option:

  • Is the skid physically close to a host system workstation?
  • Is the local HMI only used for testing?
  • Is physical control panel space a concern?
  • Is the budget really tight?

On the other hand, if standardization is your thing:

  • Common software development platforms throughout the process
  • Similar graphic look and feel across all workstations
  • Common hardware platforms
  • Standardized network cabling, or
  • Security concerns keep you up at night.

If these are important, think about matching the host system platform.

For the less advanced option, consider programming these HMIs with simple text and numeric status limited to instrumentation, equipment, and functional status of the skid. If manual override control is required (this will likely be the case if the skid is not close to a host system workstation), secure this as much as the development platform allows, and program with native objects in the simplest manner possible. Ditto for any emergency control operations you may require.

If your local HMI is on the same platform as the host system, consider presenting status and control information similar to the host system. You may simply want to insert screens or controls from the host system into the local HMI for these purposes. If you need information from other areas for effective emergency control, think about inserting host screens from those areas. Be sure that all manual and emergency operations are fully secured.

Although these local HMIs may not be used frequently, they do serve important purposes. Follow these tips to find the right design criteria for your application.

David McCarthy is president and chief executive officer of TriCore, Inc

Key concepts:

  • Even though an HMI is remote, it can be useful
  • With a little forethought, you can optimize such a system in light of larger needs in your plant 

Go online:

Learn more about TriCore at www.tricore.com

For more on HMI design, subscribe to our Information Control eNewsletter at www.controleng.com/newsletters