How to specify the right HMI

Richard Clark

September 30, 2014

13 Min Read
How to specify the right HMI
Operator interface terminal (OIT) installed on packaging machine: A basic operator interface terminal is a good fit for simple machines with limited operator interface and connectivity requirements.

Of the three basic types of HMIs to choose from, here’s how to select the best one to meet your packaging machine application requirements.

Whether you are specifying, designing, buying or selling packaging machines, the selection of the human machine interface (HMI) can have a big impact on both current and future equipment operation, compatibility and maintainability. The HMI affects not only your packaging machines, but also other connected equipment.

There are advantages and drawbacks of each of the three basic choices of HMIs: PC-based, embedded and operator interface terminal (OIT). Major factors driving selection include how end users run their business, the complexity of the packaging machine, and the connected equipment and process control system.

The packaging machine original equipment manufacturer (OEM) may have support and maintenance foremost in mind, and the end user may need to improve business intelligence and long-term equipment stability. Both are interested in security, compatibility and competitive pricing.

HMI types

There are a variety of HMIs available in the market today. The table (see Figure 4) compares each of the three HMI types based on a variety of characteristics, features and limitations. The sections below discuss these comparisons in detail, and give application examples to show where each fits best.

1. Operator interface terminal: An OIT has simple graphics, often just text and numbers, and a few touchscreen operator input points (see Figure 1). Graphics can be programmed, but only in a limited manner. For example, a four-line display will have at most four lines of characters, although each line can be customized. Similarly, the touchscreen points will be fixed to a certain amount and function, although each can be programmed.

An OIT will have just one or two basic communication protocols, so communications to controllers such as PLCs and drives is limited to those devices supporting these protocols. Remote access is either not provided, or limited to basic functions, such as transmitting a few data points via an Ethernet port using a built-in web server. These data points then become remotely accessible via a web browser. Local data logging is sometimes available, although memory will be limited, and plug-in memory expansion devices such as USB drives are generally not provided.

Most OITs can be programmed either directly at the unit or with free PC-based software. An OIT is low cost, simple to program and easy to maintain—making it suitable for a variety of small systems. But, OITs are generally purpose-built and may not be able to be modified or changed by the end user.

2. Embedded: An embedded HMI (see Figure 2) uses an embedded operating system, typically Windows Embedded 7, 8 or 8.1 variant versions of Standard or Embedded Compact 2013.

Embedded HMIs using Windows Standard versions will generally have a hard drive, a solid state drive, an attached DVD and/or USB ports. These types of devices can be upgraded and patched. 

Embedded HMIs using Embedded Compact versions cannot be upgraded without replacing the entire unit, and the processing power of these devices is usually limited as compared to Windows Standard versions.

The HMI software that runs on both of these types of embedded HMIs is purchased from a software supplier (like InduSoft) with a runtime license for its HMI software. The embedded HMI application is usually programmed on a separate development PC, and the compiled machine application is downloaded to the target HMI device.

However, some application development can be performed on the Embedded Standard machines, which makes changes or customization at a customer site quite easy and straightforward. The HMI development software license must be procured from the software supplier along with each runtime license per machine, a cost that can be spread among multiple embedded HMIs.  

Because the application is fully programmable and customizable, an embedded HMI offers unlimited combinations of graphics and touchscreen operator interface points that can be presented on a number of separate screens. Most embedded HMIs include Ethernet and serial ports and/or proprietary protocol ports (Modbus Plus, for example), fully programmable or addressable to support a variety of protocols.

Additional embedded HMI viewing options—screens—can be thin clients (an interface using Internet Explorer), a Secure Viewer (such as InduSoft’s secure thin client) or mobile access on a smart untethered handheld device via wireless or 4G cellular networks using a variety of operating systems. These extensive connectivity options are paired with web server capability to provide high-speed two-way remote access.

An embedded HMI is a good fit for applications requiring more functionality and features than available with an OIT, along with the potential to be later added to a larger process or production network. They can also be upgraded for future compatibility by choosing the correct initial operating system and hardware options for the device.

3. PC-based:For complex or large systems, a top-of-the-line PC-based HMI provides the best connectivity, remote access, graphics and flexibility (see Figure 3). However, the line between using a PC-based HMI or an embedded HMI with Embedded Standard version may be quite blurred. A PC-based HMI application is usually developed on a separate PC, and the target runtime platform is also a PC, with considerably more resources than an embedded device.

For most packaging machine applications, the target PC will be industrially rated, making it quite expensive. The target PC will generally have a powerful CPU (central processing unit), extensive on-board memory and large local data storage capability—providing best-in-class graphics, operator interface options and connectivity.

A PC-based HMI may or may not have a keyboard and dedicated video display, as it could instead have many thin clients attached to it for operator interface. It might also be used for other higher end functions such as historizing production data using a built-in SQL Server (pronounced "sequel" and stands for Structured Query Language), and/or managing other production processes besides the local machine, making it into a full-fledged SCADA (supervisory control and data acquisition) platform and justifying its higher cost.

Planning for obsolescence

While the software lifecycle for PC operating systems like Windows is typically five years, machine lifecycle is 15 years or more, with a variety of packaging equipment exceeding 35 years of life. In addition to equipment life, cost and complexity of equipment should also be considered.

With PC-based and embedded systems, obsolescence of operating systems is a concern within about five to 10 years of installation respectively. While the OIT may have 15 years or more of life, it will likely need to be replaced or upgraded before the mechanical equipment has made its last package.

Even after support ceases for an embedded or a PC-based HMI operating system, the unit can continue to be used. However, there will be no more security patches provided for the operating system, potentially weakening security of the device. If changes are desired to any of the three types of HMIs after support for the original operating system ceases, an older PC with the discontinued operating system must be available to run the HMI programming software, or the device must be upgraded to something more current.

As an alternative for embedded and PC-based HMIs, a new embedded or PC target with the latest operating system can be purchased. But, embedded and PC-based HMI software suppliers vary widely in their ability to migrate their applications from one platform to the next, an important consideration, as application development is often a significant expense.

Some suppliers make it easy to port an application from a discontinued operating system to a new one, while others make it a time-consuming task requiring extensive application reprogramming. For example, InduSoft applications are completely backward compatible, and applications that have been running on old operating systems using an old version of InduSoft Web Studio will run on any current version and operating system.

Purchasers should therefore perform a close examination of the supplier’s past support in terms of porting applications. If the supplier can port applications from a 90s-vintage Windows operating system to today’s current standard, chances are they will be able to provide this same type of application portability in the future.

The cost and complexity of the equipment often drives the HMI selection. An OIT may be perfectly adequate for a simple bulk bag filler, as well as other items of equipment with limited required local operator interface, connectivity and flexibility.

As system complexity increases, embedded and PC-based HMIs have an advantage due to improved screen resolution, number of screens available, tag count, expansion options and connectivity.

Most HMIs will require connections to other devices, in some cases extensively.

Secure connections

OITs have limited connectivity and often use proprietary industrial protocols, making them highly secure. Communication from the OIT to its associated controller is generally easy to set up and trouble free, but connectivity to upper level computing platforms is either not available or strictly limited.

Embedded and PC-based HMIs will have Ethernet ports and use open protocols, providing connectivity to almost any platform, but also increasing security risks. These risks can be mitigated by purchasing the right software, programming the application with security in mind, and maintaining the operating system and the applications as patches and upgrades are provided by suppliers.

Plant standards for hardware and connectivity can drive HMI selection. For example, a plant may have standardized on the EtherNet/IP protocol, and require each of their HMIs to have appropriate built-in communication capabilities.

In addition to meeting current requirements, future connectivity needs must also be considered, particularly to higher level computing systems. For applications ranging from simple production tracking to business intelligence functions pulling together and analyzing data to improve business operations, you’ll need connectivity to external computing platforms, such as ERP systems and historians.

Users should therefore consider the need to collect, analyze and report data in a usable format when specifying HMIs. What will be done with large amounts of raw data once it’s collected? If the data needs to be filtered and visualized in a way that provides timely business analysis and decisions, consider software featuring business intelligence templates. These templates allow the creation of key performance indicators (KPIs) and other software dashboards with simple software configuration rather than custom coding.

Many end users are demanding their machine builders/OEM suppliers use remote access to provide quick and low-cost service and support within the warranty period, and sometimes afterwards via maintenance agreements. In addition to troubleshooting problems as they occur, these services can include remote diagnostics and preventive maintenance.

OITs typically don’t provide much in the way of remote access, at most making a few data points available. Even this limited functionality often requires custom programming to interpret the data output from the OIT and convert it to a format amenable to remote access.

Embedded and PC-based HMIs will have a built-in Ethernet port and web server, providing remote access via any browser. This allows remote access not only from a PC, but also from tablets and smartphones. 

Although all modern embedded and PC-based HMIs provide remote access, the quality varies widely. Remote access from a PC is simple, as the remote PC simply duplicates the local embedded and PC-based HMI screens. Security is provided by using operating system functions and features, and by programming the HMI to give varying levels of access to each user based on log-in credentials.

But remote access via tablets and particularly smartphones is another matter, and HMI suppliers differ widely in their ability provide this information that can be easily viewed on a smaller screen.

In the worst case, the HMI supplier simply makes the local screens available on a remote smartphone, requiring the users to compress, pan and expand to locate and interact with the area of interest.

Some HMI suppliers go much further, providing built-in tools for creating operator interface screens especially for tablets and smartphones. If the HMI software supports the HTML5 standard, then it can be used to easily develop screens for any tablet or smartphone supporting the standard.

In terms of security, the HMI can often be used to shield controllers from the outside world, while still providing local and remote access to the data contained within these devices. This is done by routing all communications to the controllers, drives and other connectable plant floor devices through the HMI.

The right HMI will have extensive security features built-in—much more than any plant floor device—allowing developers and users to configure a highly secure system. The HMI will, in turn, be securely connected to a variety of platforms, such as an ERP system, a historian and remote access tools. This security is particularly important when using more advanced HMI features, such as the ability for remote users to acknowledge alarms and make changes to setpoints.

Improving the operator experience

While remote access is important, the heart of any HMI is its local operator interface capabilities, an area where embedded and PC-based HMIs shine.

Graphics and the operator experience with HMIs have been continuously improving for years. Even the OIT, with its somewhat limited and fixed graphic feature set, has made strides in terms of display capabilities, in some cases offering limited programmability of its basic graphical elements such as gauges, dials and buttons.

If your equipment requires little in the way of graphics and data display, an OIT can fit the bill.  However, if your application requires extensive graphics and operator input, or if flexibility is important, an embedded or a PC-based HMI should be specified.

The wide age range of manufacturing personnel offers a span of experience and perspective.  Workers who have grown up in the digital age expect HMI interfaces with intuitive screen content and interaction, specifically multi-touch commands to quickly access content. Studies have shown multi-touch provides three times faster screen interaction than single touch—not surprising in view of how users easily interact with tablets and smartphones.

The manufacturing environment and its suppliers are more conservative and expect longer operating lives than the two-year cell phone contract, so the transition to multi-touch will be a gradual process. However, many embedded and PC-based HMIs have this capability now, and multi-touch should spread rapidly now that support for it is included with the latest version of Windows.

Ease of use can be programmed into all HMIs from an OIT to PC-based HMIs, but embedded and PC-based HMIs can provide a more powerful graphical user experience, allowing operators to understand and act on information quickly. This improves productivity, reduces downtime and helps avoid incidents.

If an intuitive and interactive HMI, communicating with a variety of equipment and collecting significant amounts of searchable and specialized data is required, an embedded or a PC-based HMI may be required. The OIT may not meet be able to meet these requirements, although it will always have its place in simple applications where cost is a primary concern.

In a nutshell

Cost and size of the application are big drivers when selecting the type of HMI. For small applications, where operator interface requirements are fixed and limited, and where communications are only required to the associated controller—an OIT, with its long life, low cost and small size, is often sufficient.

As the application size increases along with the amount of controller I/O and process complexity, operator experience requirements increase—and the embedded HMI becomes the better fit. Compared to an OIT, it has improved connectivity, remote access, graphics and flexibility. This option is also less expensive than a PC-based HMI, has a smaller footprint and uses an operating system with about double the life expectancy of a PC.

A PC-based HMI is the logical choice for large applications with connections to multiple systems via many different protocols. It will provide extensive remote access, advanced operator interaction and maximum flexibility—albeit at a high cost with a limited life span.

Most packaging plants will end up with all three types of HMIs. And careful upfront planning will ensure that the right HMI type and brand is specified for each item of equipment and application area.

Richard Clark, engineer at InduSoft, has extensive and in-depth technical expertise encompassing both IT and control systems engineering. He has also been a professional technical writer for more than 15 years.

Sign up for the Packaging Digest News & Insights newsletter.

You May Also Like