Do it yourself HMI

Technology Update: Should you build or buy a human-machine interface (HMI)? Developing PC-based HMI software may seem a simple task, but there are pitfalls. Configuring a purchased HMI software package is often a better long-term option. A table compares HMI software development versus configuration.

By Richard Clark June 8, 2015

PC-based human-machine interface (HMI) software has been around since its original introduction by Wonderware in the 1980s. Machine builder original equipment manufacturers (OEMs), system integrators, and end users saw its potential immediately, spawning the success of many additional HMI software companies.

But many users also saw the potential to develop their own PC-based HMI applications, motivated primarily by the desire to avoid up-front costs for HMI development software packages and runtime licenses.

Now that we’re decades into these developments, we can look at each approach and evaluate advantages and drawbacks. While buying makes sense for many, making is a viable approach in some instances.

When to develop software internally

While creating an HMI application may seem relatively simple to an experienced programmer, maintaining the software over the long-term inevitably turns into a major effort. For this reason, internal development of HMI software should only be undertaken when the following conditions exist.

First, internal development typically doesn’t make sense for an end user as there simply won’t be enough deployments over which to spread development costs. It might make sense for a machine builder OEM, but only in certain circumstances.

  • The OEM must produce machines in large volumes to amortize development costs over many units.
  • The HMI application should be relatively simple to keep development and maintenance costs down.
  • There must be at least two capable HMI programmers in-house.

Two or more programmers are needed because reliance on one individual isn’t a good idea, as the HMI application is not finished after the first machine is up and running but must be maintained over the life of the machine, which often spans decades. If there’s only one programmer, and the person leaves the company, maintenance becomes problematic. With two or more programmers, software maintenance can be handled jointly, a much safer approach. New programmers joining the company must also be fully trained to maintain continuity.

The embedded approach

If all of these conditions are met, internal development of HMI software can be a viable option, but one more factor should be considered. If the HMI application is relatively simple, which is a requirement for internal development, purchasing embedded HMI software can be a better choice than either internal development or a purchased PC-based platform.

With the embedded approach, the OEM buys display hardware with an HMI runtime license already installed (see Figure 2). While an embedded HMI may not have all of the features of a PC-based HMI, most offerings are certainly capable enough for many OEM applications, and they will always be much less expensive than a PC-based HMI, both upfront and long-term. But if the embedded HMI approach just won’t work for some reason, and if the OEM is determined to develop the application in-house, these concerns must be addressed.

Updating complications

Internal development of HMI software is much simpler than it was decades ago, primarily due to the emergence of better programming languages such as Visual Basic. Most of these languages can run on Linux- or Microsoft Windows-based platforms.

Linux will be the less expensive option because the software is cheaper than Windows and because the Linux box will be cheaper than a PC. But using Linux adds even more complexity to the equation, so only the PC-based approach is discussed below.

Problems with the PC-based approach often arise after the first application has run through its lifecycle for the initial machine application. At that point, a new or upgraded machine is introduced, and the software must be updated. Other problems may surface due to new versions of operating systems or hardware platforms that no longer support the existing code.

Updating the HMI software for a new or upgraded machine may not be overly difficult if the original programmer is still around. Not only can the software be upgraded, new features can also be added, and bugs can be fixed.

The same is true when the operating system or hardware platform is made obsolete, but in this case the drawbacks of the in-house approach surface as compared to purchased HMI software.

With purchased software, the supplier will typically have new versions of the software ready to go upon introduction of a new operating system. Some suppliers provide import functionality so older HMI applications can be easily upgraded to the new operating system, making this task relatively simple.

When the software is developed internally, the task of ensuring compatibility with the new operating system falls to in-house resources, adding greatly to costs.

These upgrade issues are significantly exacerbated if the original developers are no longer with the OEM, particularly if the code wasn’t documented properly. 

Transferring ownership

If none of the original developers of the HMI software have remained, it becomes necessary for one or more new developers to take ownership of the existing and new applications. Significant time is often needed to determine how to fix or change the feature set.

The same is true when creating and incorporating new functionality and then testing the results to ensure no new issues have been introduced. Bug fixes in particular can be problematic, as this task often requires in-depth knowledge of the HMI software.

Transfer of ownership is made easier if the original software and all subsequent changes were made in a structured fashion and meticulously documented, but this is not typical. In most instances, HMI software is developed and maintained somewhat haphazardly, making it difficult or even impossible for the new programmer to maintain the application.

In many, if not most cases, an HMI developed internally often relies on programming tools and methods unfamiliar to a wide group of programmers, and eventually its viability begins to rely on the one person who created the HMI. If that person is no longer around, the new programmer must reverse engineer the code, a time consuming and very difficult task.

To avoid these and other issues, a better choice may be to purchase HMI software from an established supplier, and then configure this software for the particular application. While configuration of purchased HMI software does require some expertise, it’s a much simpler proposition than writing code from scratch.

Buy instead of make

While internally developed HMI programs are successful in some applications, software packages such as Wonderware InTouch Machine Edition have a short configuration learning curve compared to VB.NET and C# code development, deployment, and maintenance.

Modern HMI software packages provide intuitive interfaces to develop most necessary functionality (see Figure 3). They also typically contain the connectivity required to interface to most real-world hardware devices in a variety of protocols, simplifying system configuration.

Purchased HMI development software, with its built-in advanced tools, helps reduce many of the issues encountered by new users. Configuration of functions and communications using fill-in-the-blank panels reduces problems and development time.

Many built-in HMI features would be very difficult or impossible for an OEM to develop from scratch. Purchasing HMI software eliminates the need for the OEM to "reinvent the wheel" when configuring a full-featured HMI application. 

Use an integrator

If in-house resources are insufficient to configure the purchased HMI software, or if the application has a very high degree of complexity, an OEM can use a system integrator. The integrator should be certified by the HMI supplier, as this will ensure a level of competence with the product and a track record developing successful HMI applications.

This may be a prudent choice as the right integrator will have the resources to provide technical support via an engineering staff with years of experience in a variety of applications and industry verticals. This can help an OEM get its equipment to market quickly.

If for some reason it is not possible to use the same integrator for product updates or improvements, the software supplier can provide contacts for other certified integrators to take over project development and maintenance.

This option can be a particularly good choice if the OEM has an on-going partnership with an integrator familiar not only with the HMI software, but also with the OEM’s specific applications. When internal resources aren’t sufficient, and when a suitable integrator isn’t readily available, the HMI software supplier may be able to assist. 

Engage the supplier

A quicker and possibly more cost-effective solution is to engage the services of the HMI software provider (see Figure 1). This option provides direct access to experienced application engineers who can debug an existing application or build a turnkey solution from the ground up.

While all HMI software suppliers offer some level of support, associated costs vary widely, as does the extent of services provided. Some suppliers provide free or low-cost support, while others charge quite a bit more. Some suppliers offer turnkey solutions, while others prefer to refer customers to integrator partners.

But if the HMI software supplier does offer a sufficient array of services at a reasonable cost, this can be an attractive option since no one knows the software as well as the supplier. Very often, the software supplier’s staff will have a great deal of experience in creating safe and secure software applications for OEMs and other customers.

While internal development of HMI software is easier now than in years past, configuring purchased HMI software is simpler. And internally developed software has other pitfalls, particularly with respect to long-term maintenance of deployed applications (see Table 1). As many OEM machines have life spans measured in decades, software maintenance will be required, and it’s simpler to maintain applications configured using purchased HMI software.

– Richard Clark, an InduSoft Web Studio application developer at Wonderware by Schneider Electric; edited by Mark T. Hoske, content manager, CFE Media, Control Engineering, mhoske@cfemedia.com.

Key concepts

  • Various tools make do-it-yourself HMIs a tempting choice.
  • Costs of creating an HMI extend far beyond initial investment; wait for the upgrades.
  • Maintenance of deployed applications can be considerably easier with purchased software.

Consider this

Lower initial cost of do-it-yourself software may not make sense after considering lifecycle costs.

ONLINE extra

Richard Clark, as an InduSoft Web Studio application developer, oversees marketing, engineering, support, and security of third-party products for Wonderware by Schneider Electric.

– See additional stories about information systems and HMIs below.