Integrating HMIs with PLCs and PACs

Understanding the differences among controllers is essential when designing an automation system.

By Jeff Payne June 6, 2014

Today’s industrial manufacturing, utility, and distribution companies require extensive data collection and analysis to stay competitive. Although newer automation technologies have made it relatively easy for these businesses to gather tremendous amounts of data, simply collecting data isn’t sufficient. To achieve continuous improvement goals, these data must be presented to users in ways that facilitate analysis through user-friendly displays and interfaces.

Analysis is where data acquisition shows its real value, as this is where areas for improvement come to light. Application requirements not only help define the type and method of data acquisition, but also affect how these collected data are analyzed.

However, before analysis can take place, local and remote human machine interfaces (HMIs) are required for real-time monitoring and control-and in some instances for data handling. There are different approaches for integrating programmable logic controller (PLC) or programmable automation controller (PAC) data with HMIs. Tight integration between data gathering and presentation can help businesses improve diagnostics and overall system performance.

PC-based or embedded HMI?

An HMI can be a PC running off-the-shelf software configured for the application, or an operator interface terminal (OIT) with an embedded operating system and prepackaged software. PC-based software usually offers more functionality, while an OIT provides simpler setup and operation at a lower cost (see Figure 1).

Whether selecting a PC or an OIT, software must be configured by the end user for the specific application. Custom, complex, or advanced applications may require programming in a development environment, such as C++ or Visual Basic. However, most applications can be handled by configuring off-the-shelf software programs-a simpler process.

PC-based HMIs typically use a Windows operating system and provide easy connectivity to a multitude of PAC and PLC controllers. This class of HMI features high-end performance, but costs are relatively high as users must purchase a PC and the HMI software.

OITs generally don’t include all of the features of PC-based HMIs, but they are lower in cost-both up front and in operation. Deployment is also much simpler as the HMI software is closely matched to the embedded operating system. A PC is typically used to configure the HMI software for the specific application, which is then downloaded to the target OIT.

Tightly integrated communications

HMIs are the key vehicle for providing a user interface for almost any industrial application including machine control, discrete part manufacturing, and process control. PLCs and PACs are used to control the equipment and processes, so it’s natural they should be closely integrated with HMIs and OITs. Most PC-based HMIs and OITs include driver software to communicate with a wide range of popular controllers, eliminating the need to write, test, and maintain custom communication driver software.

In addition, common networking protocols, such as various flavors of Ethernet, exist to allow these distinct technologies to communicate. This has made integration much easier, and an HMI or OIT can be quickly programmed to extract data from or push commands to the controller.

Although an HMI or OIT and a controller can communicate at a basic level, they may not be truly exchanging data in the most effective and efficient manner. Moreover, there are key differences in how to integrate an HMI or an OIT with a PLC, as opposed to communications with a PAC.

PLC and PAC differentiators

Modern PLCs and PACs are designed to satisfy the complex requirements of today’s automation applications. Over the years, these controllers have evolved into full-featured systems, especially in terms of data collection.

Both PLCs and PACs can store data internally, or they can transfer it to other systems. Communications from either controller to other computing systems including HMIs and OITs are typically performed through an Ethernet port, which is built into most modern PLCs and PACs. The support of popular Ethernet and other protocols negates the need to write complex drivers to exchange data between the controller and external systems.

PLCs have been around for more than 40 years. However, recent advances have greatly increased their capabilities. PLC-HMI integration advantages include:

  • Lower purchase cost
  • Greater familiarity for users
  • Better for simple machine control
  • Excellent execution speeds from advanced PLCs
  • Combined PLC/OIT devices for lower end applications.

However, these increased capabilities have led to some confusion as to which type of controller is best suited for each application.

In general, PLCs work well for machine control-both simple and high speed. But an architecture based on ladder logic and a focus on discrete on-off control can make expanding a typical PLC beyond its original capabilities difficult.

For example, an older or lower-end PLC often requires the addition of separate hardware cards to accomplish functions outside its core capabilities, such as networking among multiple components, extensive process control, or sophisticated data manipulation.

On the other hand, a PAC is geared more toward complex control and data handling. It’s also usually a better match for applications with extensive process control requirements because a PAC is more capable in handling analog I/O and related control functions.

Another relatively new device on the market is the integrated PLC/OIT. By combining the controller and interface into one device, costs can be lowered significantly. These combination PLC/OIT units provide simplicity and minimize the amount of required cabling and cabinet space. However, these solutions are not a replacement for standard PLCs and HMIs or OITs in more complex applications.

Because they share a common CPU and memory, these resources can be taxed. The main function of a PLC is real-time control, and if the OIT portion is using a lot of processing power and/or dynamic memory, the control functions can be compromised. Therefore, these devices are best suited for lower end applications, not those with high I/O counts and more advanced functionality requirements.

When a combination PLC/OIT unit isn’t sufficient, it becomes necessary to integrate the PLC or the PAC with the HMI or the OIT.

See the next page for more about pairing a PLC with an HMI or OIT.

Pairing a PLC with an HMI or an OIT

To meet the demand for more PLC functionality, some manufacturers have added advanced features and capabilities. For example, older PLCs could usually accommodate a maximum of 16 PID loops, but new versions can handle thousands. These advanced PLCs also offer more processing power, communication ports, and memory compared to older models.

Although the distinction between PLCs and PACs is becoming less apparent, there’s still a fundamental difference with regard to tag databases. Most standard PLCs aren’t tag-based, but instead use fixed-memory addresses. This means all references must use the cryptic fixed memory location, as opposed to a more user-friendly tag such as "Tank Level High."

This complicates the integration of the controller with the HMI or OIT as it adds extra programming steps. An easier way to integrate is available in the form of a PAC.

HMI-PAC integration

PLCs have been around for decades, but PACs are fairly new. Designed for data handling, PACs can be simpler to integrate with HMIs, particularly in applications with extensive data requirements. PAC-HMI integration advantages include:

  • Less development time
  • Integrated tag database hosted by the PAC
  • Modular design for easy expandability
  • Designed to be integrated more tightly with SQL and other databases
  • Better suited for analog I/O and related control functions
  • Provides a single platform suitable for multiple domains.

The PAC’s modular design also facilitates system expansion. When requirements dictate the use of a PAC, in most cases, a high-end HMI will be the best fit for the operator interface, as opposed to a simple OIT.

When it comes to HMI integration, one of the most important PAC features is its tag database with its aforementioned real-world tag names. Because the PAC has extensive memory, it can host the database, and act as a central repository to collect, store, and distribute data not only to the HMI, but also to other components and systems.

Having a tag database in tightly integrated systems means each component of the automation system can pull from the same database. During the initial phases of a project, this feature saves users a tremendous amount of time and resources by reducing the development effort by as much as half. Using a common PAC-based tag database also eliminates the time-consuming task of mapping fixed internal addresses over to common protocol reference addresses.

With a PAC, cryptic data monikers still exist in the deep files of its memory but are never presented to the user. The user simply creates a real-world descriptive tag name such as "Tank Level High," and this tag name is automatically mapped into the correct memory location (see Figure 2).

There are many considerations when selecting a controller and integrating it with an HMI or an OIT. A PAC is better suited for data handling and offers advanced features, such as a tag database, that simplify integration. But it’s more expensive than a PLC, and it takes a bit longer to implement. A PAC often works best with a PC-based HMI, as both components represent the high end in terms of performance.

PLCs, on the other hand, offer widespread familiarity, compactness, and a lower purchase price. For machine control, a PLC is the better choice, and it often makes sense to pair it with an OIT. For the simplest applications, a combination PLC/OIT unit can be the best choice, as it will be the lowest cost option.

There is no right or wrong choice when deciding among PLCs, PACs, HMIs, OITs, and combination units as each has its own unique advantages and disadvantages. By better understanding the differences among these components, including the integration requirements, users can make more informed decisions and select the right solution for their applications.

Jeff Payne is a product manager at AutomationDirect.

This article appears in the Applied Automation supplement for Control Engineering and Plant Engineering