How to deploy smart HMIs as communication hubs
An embedded or PC-based smart human-machine interface (HMI) can connect to many types of servers, controllers, smart components, and input/output (I/O) devices through a variety of drivers and networks. These connections are facilitated by menu-driven commands, pre-packaged drivers, and built-in support for various protocols.
Once these connections are made, the HMI can be remotely connected to a wide variety of smart devices including PCs, smartphones, and tablets. These connections provide remote operators with overview of the machines and processes for troubleshooting and optimization. Data and production information can be sent to engineering, and management can view summary and analysis information.
The smart HMI acts as the hub for data gathering and information, with the ability to process collected data and turn it into actionable information.
Smart HMIs are typically embedded or PC-based. As the name implies, an embedded HMI runs on an embedded operating system. Embedded HMIs are dedicated to one function of hosting the HMI application, so they require fewer computing resources than a PC-based HMI (Figure 1).
As compared to an embedded HMI, a PC-based HMI is more powerful, expandable, and flexible (Figure 2). But, a PC-based HMI will almost always be more expensive to purchase, install, and support.
PC-based HMIs consume tremendous amounts of resources compared to embedded HMIs. Having said that, there is a place for both models. When used as a communication hub, many disparate machines or technologies may be used and need to be connected, and using a PC-based HMI/SCADA node is often the preferred choice in this circumstance. [SCADA stands for supervisory control and data acquisition.]
Two of the main capabilities setting PC-based HMIs apart from embedded HMIs are connectivity and data handling. Although an embedded HMI can handle a considerable amount of data related to the application it’s monitoring, in larger applications, a PC-based HMI can serve as a hub for database storage and information dispersal.
For example, a PC-based HMI can host many remote multi-touch display screens and/or thin clients, which could serve as information centers in a public location. It can support multi-monitors as a display, including live video feeds. At the same time, it can support other operations and server functions requiring large processing resources, tasks beyond the capability of an embedded HMI.
On the other side of this coin, modern embedded HMI’s are becoming more flexible and easier to connect to other components. Built-in web server capability and support of HTML5 browsers provides freedom from previous custom programming requirements. Custom programming was typically implemented via Java-only, ActiveX, and .NET plug-ins, and from other technology libraries that require proprietary plug-ins to run or play graphical content. But support for the HTML5 standard within the embedded HMI platform allows creation of graphics that can be accessed by any web browser hosted on virtually any remote device, providing nearly universal Internet of Things (IoT) connectivity.
These connection and graphics capabilities illustrate how embedded HMIs are merging with the PC-based HMI world. The embedded HMI is also becoming more secure, making it safer to use in an IoT environment.
Many embedded and PC-based HMIs provide a variety of tools to simplify connectivity. Some HMI software technologies provide more than 200 built-in communication drivers, allowing easy connection to a wide variety of controllers, smart components, and I/O.
These smart HMI configurations support many types of drivers to provide connectivity to disparate devices, so connections to external devices via smart HMIs can use virtually any connection type or protocol. Many of these connections are TCP/IP-based because most modern automation components have an Ethernet port.
One HMI program, for example, includes drivers supporting a number of connection types including Ethernet TCP/IP and other Ethernet protocols, serial, and proprietary methods. Protocols supported include Modbus TCP, Profinet, DNP, IEC 60870-5-104 Transmission Protocols, BACNet, CAN (ISO 11898), various automation vendor protocols, and others. [Governing organizations for the protocols are, in order, Modbus Organization, PI North America, DNP Users Group, International Electrotechnical Commission, BACnet Advocacy Group, and International Organization for Standardization.] Some smart HMIs also include what’s referred to as a "raw driver," which enables development of custom protocols for devices incompatible with any of the drivers provided with the HMI software.
Whether connected to a smartphone with limited screens, a tablet with multi-touch, or even multi-monitor applications, the built-in features of these HMIs provides many connection options.
Integration to other platforms
Smart HMIs not only connect to controllers, smart components, and I/O-they can also connect to many other platforms and computing systems, local to the plant and remote (Figure 3). These connections are usually Ethernet-based, and can be made through a wide range of supported protocols, such as EtherNet/IP, Modbus TCP/IP, Profinet, and others.
The attributes and features required to support this connectivity are listed in the Table and discussed in greater detail below.
It starts with being able to have an HMI runtime installed and running on Linux, Google Android, Wind River (Intel) VX-Works, Apple iOS/OS X, and a number of other operating systems and platforms. HMI software with a small footprint helps provide this flexibility, as required system resources are not excessive.
Connectivity with smart HMIs is extremely flexible and very scalable. Connected hardware platforms can be virtually anything that is currently offered by automation and IT vendors, or something custom designed as a unique system.
The connectivity of the smart HMI enables historians and databases of all types to be used to store data, events, and alarms. This gives access to a wide array of printing and reporting capabilities. It also permits integration to third-party software suppliers with specific offerings such as a graphic library management tools or statistical process control functionality.
Thin clients can be used to expand the connectivity of the smart HMI. These thin clients typically connect over any TCP/IP connection such as local area network (LAN), wide area network (WAN), modem, and satellite. They can read and write information from the smart HMI server via any Web browser. Users interact with the screens at the thin client, just as if they were in front of the main HMI server application screen. This type of connection works well to add displays anywhere on the plant floor, in offices, or even remotely.
A smart HMI can serve as a security and data gateway, protecting equipment and platforms from intrusion from unauthorized access. It can also allow applications to freely share information, without the need to alter existing legacy systems.
OPC eases communications
Once hardware connectivity is established, the next step is to interpret the data received by the HMI from the various connected controllers, smart components, and I/O. OPC technology [from OPC Foundation] is often used as a common language in the world of industrial communications, allowing components from various vendors to work together through the HMI.
Smart HMIs with an OPC XML add-on allow users to communicate with devices using a standard XML format. OPC XML works on a server/client architecture, and allows seamless communication among devices using this protocol.
OPC Unified Architecture (OPC UA) is a protocol released in 2008 that is actively being promoted as a universal, secure communications technology that is scalable. OPC UA has been built into communications chipsets for IoT devices, allowing integration across an enterprise, starting with single devices. Whether using an embedded HMI or PC-based HMI, the software should support OPC, and have drivers compatible with OPC legacy protocols and with OPC UA.
Because a smart HMI can be easily accessed from a wide variety of platforms and devices located almost anywhere, security is a must, and should be built into the HMI.
Connections to the HMI must be secure, particularly from devices located outside the plant. Fortunately, smart HMIs have a number of built-in tools to establish, monitor, and maintain secure connectivity.
Security gateways in a platform or enterprise need to authorize and authenticate devices and users. Smart HMIs can supply this functionality by providing a security model within their architecture, or by using Lightweight Directory Access Protocol (LDAP, from the Internet Engineering Task Force) to allow another system (e.g., Active Directory) to manage users over an Internet Protocol (IP) network.
Additionally, there must be a way to encrypt communications and data, along with providing SSL (HTTPS) and VPN connectivity when needed. A smart HMI can provide security in these and other ways.
The HMI must have a means to secure intellectual property created during the development of application and hardware platforms. This keeps screen creation and the ability to change the applications in the development environment safe and secure through the use of passcodes and encryption. These features give creators of HMI applications the ability to protect their work from modification or intellectual property theft.
Depending on the operating system on which it is installed, a smart HMI can be anything from a simple remote interface using an HTML5 browser in a handheld device, to a number of fully featured and configured operator interface terminals for use in an entire plant or facility.
The smart HMI can be securely connected to a wide variety of servers, controllers, smart components, and I/O—thereby acting as a communication hub for the entire industrial automation system.
– Marcia Gadbois is InduSoft vice president at Wonderware by Schneider Electric. Edited by Eric R. Eissler, editor-in-chief, Oil & Gas Engineering, email@example.com.
- Smart HMIs are typically embedded or PC-based.
- PC-based HMIs consume tremendous amounts of resources compared to embedded HMIs.
- OPC UA is a newer protocol that is actively being promoted as a universal, secure communications technology that is widely scalable.
The connectivity of the smart HMI enables historians and databases of all types to be used to store data, events, and alarms and these abilities provides access to a wide array of printing and reporting capabilities; important of documenting and analyzing system processes.
See the Control Engineering HMI, OI page.
– See related stories linked below.