It used to be that, when deciding on a complete automation system software solution including human-machine interface (HMI), you selected the actual control software package or packages for sequencing, logic and motion, and then you chose a separate HMI program from a company that specialized in HMI software.
Or perhaps you created your own HMI by programming it yourself in one of many programming languages, such as C++ or Visual Basic. But many major controls automation software companies now include an HMI environment as part of the complete automation programming suite.
I am referring to this inclusion of an HMI programming environment into the standard automation package as an integrated system and specifically talking about the addition of a visualization editor as part of the familiar programming package—adding soft buttons, tanks, levels, valves, status indicator lights and so forth to the layout to create a custom interface for the factory line or process.
So, what exactly are the advantages of an integrated approach versus picking a separate HMI program for the front end? And when does it make sense to skip the unified approach?
To start, the performance of an integrated system is often better and reliability is improved due to streamlined communications and less overhead needed. These integrated systems often provide built-in communication and data sharing between the HMI and control logic, allowing variables, alarms, status indicators and real-time data to be accessed without the need for separate OPC servers or middleware to facilitate the communication. This results in tighter integration and synchronization, faster updates, fewer communications errors and lower latency between the operator interface and the control software and hardware.
On a similar note, running fewer disparate programs and data servers reduces the processor load and memory requirements on the industrial PC (IPC) that is the automation controller. More power is then available for other tasks, faster and more reliable control system behavior or the corollary; a smaller controller can be used for the same program runtime.
Often, the HMI and control tasks have their own diagnostics, error handling and system logs that are useful for troubleshooting the root causes of issues via runtime errors and other system information. With an integrated platform, these diagnostic tools are a shared resource, producing a unified system log, making troubleshooting easier and quicker, reducing downtime and giving the engineer a clearer root cause analysis.
A unified development environment with a shared toolchain—project editor, tag manager, diagnostic tools—that includes control and HMI programming also simplifies development. First, the development engineers do not have to juggle multiple development environments or keep track of duplicate tags and variables used across multiple platforms. This reduces development time and results in fewer programming and runtime errors.
Second, the reduced system complexity that results from not needing separate data servers, additional interface protocols, such as OPC UA or Modbus, or extra runtime environments means there are fewer components that have to be configured, integrated, troubleshot and maintained. This results in a reduced engineering effort while providing a more robust, easier-to-maintain system.
Get your subscription to Control Design’s daily newsletter.
From a purchasing perspective, licensing two or more separate development environments and runtime licenses can get expensive. With an integrated solution, vendors often provide bundled licensing models, reducing the total cost of ownership.
Version control mismatches between HMI and control software can also be a common source of runtime bugs and headaches for the developer. Having one project file that contains both the HMI and control logic makes it easier to manage updates and backups of the running program images, and it takes the confusion out of which HMI and PLC images are compatible and the most recent—no clever naming conventions that supposedly make it clear which versions go with which. The result is consistent system behavior and an easier migration path for improvements or rollbacks to earlier versions, if needed.
So, when might separate software be better? While integrated packages are generally advantageous, separate packages may be preferred when you are mixing best-in-class tools from different vendors based on customer requests, especially in the case of original equipment manufacturers (OEMs), or if certification and traceability requirements are required for certain industries and are qualified by only certain vendor programs. Or perhaps you need modularity or vendor independence for perceived long-term support flexibility. Another case may be if you have IT or cybersecurity constraints that require isolation of control and visualization layers.
Unless you have a special situation that dictates that a separate HMI package is used, the integrated approach seems to be the obvious path forward. Just as merging sequential logic and motion control in control software in the past decades was a sea change, the benefits of improved diagnostics, performance, reduced costs, engineering effort and better version control all point to a future of integrated HMI and control software.
