HMIs Move Beyond Interface Status
EP Editorial Staff | February 12, 2020
Modern human-machine interfaces can collect, store, and process data into helpful information and communicate it to those who need it most.
By Marcia Gadbois, ADISRA
The core mission of human-machine interfaces (HMIs) is concisely and clearly expressed in the name. Modern industrial HMIs provide a graphical way for electronic systems to provide information to operators, who in turn can use the HMI to initiate actions. The newest HMIs can provide much more functionality, particularly with respect to data handling and processing.
Many end users and original-equipment manufacturers (OEMs) would like to take even greater advantage of HMIs, knowing they offer much more than neat icons and touchscreens. Factory-automation HMIs have evolved beyond the traditional dedicated, fixed-in-place devices installed on machines. Users can now interact with HMIs using a PC, phone, tablet, wearable device, or even a headless edge device by opening a browser to view HMI screens and data. A single HMI application can be tailored with different screens for different users, based on their requirements.
HMIs can collect data from sensors and IIoT (Industrial Internet of Things) sources, store it, and process it into useful information. HMIs are typically and conveniently located close to the data source and can also fulfill the role of transmitting processed information throughout an organization or to the cloud to support analysis.
A basic HMI might show operators the status of a process at the moment. A more-capable HMI can help those same operators better understand what is happening and provide maintenance and management personnel with the information they need to improve operations.
The Edge Advantage
Edge computing, by definition, suggests systems capable of extracting and processing data and information from as close to the data source as possible. HMI applications are ideally positioned for the task. Traditional standalone HMIs are usually located near, or on board, associated processes and machines, out at the operational edge. Processing the data close to the source naturally reduces upstream network bandwidth costs and utilization.
In addition to conventional wired sensors, there are increasing numbers of smart systems and IIoT devices in the field connected through wired or wireless networks to HMIs and able to supply a lot of extended data. Growing adoption of wireless connectivity, possibly including the new 5G network in the future, will accelerate the adoption of remote IIoT support for industrial systems and data.
Accessing and processing data at the edge used to require a full-blown supervisory control and data acquisition (SCADA) system. This is no longer the case. In many applications, the edge devices are PLCs or other intelligent-control-system elements, along with IIoT field devices. With an enhanced HMI application, the data from these edge devices can be accessed and evaluated by an HMI application at the edge without the need to first bring the data back to a central point.
In fact, an enhanced HMI can employ various techniques and standards to move the massaged or raw data to a cloud-based supervisory database directly, without the need for SCADA. The distinction between HMI and SCADA is thus blurred as modern HMIs can deliver a full SCADA experience.
Mature but not Minimized
Although the modern HMI is a relatively mature technology in many ways, hardware and software developments mean that HMIs are poised to deliver many other capabilities to improve the overall HMI experience while enabling better human-machine communication.
Fancy screens and blinking icons have populated HMI screens for years, providing real-time understanding of machine and process dynamics. There was little going on behind the scenes in a typical HMI application, with any additional requirements handled by a SCADA system.
But today, HMIs have matured and adapted to the changing landscape, becoming more informative and intuitive. The IIoT and big data have changed the conversation surrounding HMI. End users want data in various forms (raw, aggregated, and pre-processed) to achieve their desired goals, including determining analytics results, key process indicators (KPIs), and certain enterprise and process metrics.
Achieving these goals provides benefits for end users and OEMs alike. A ‘new and improved’ HMI can be used as a hub or collection point for all data, as well as for data handling and processing.
HMI evolution has always kept pace with technology while remaining cognizant of the need to interface with legacy systems. This evolution now includes expanded HMI capabilities for handling data, pre-processing it, communicating it to higher-level systems, and interfacing with the cloud. One particular advantage of these new HMIs is the ability to extract and share data from disparate systems, for example by using OPC UA and other industry standards.
Industrial automation data gathering has typically been performed at a high level in the control-system architecture, usually on-premises by a SCADA system. This is still a good model, but it can be supplemented or even superseded by HMIs configured to gather real-time field data, store it locally, and then replicate or forward it to a higher level on-premises database or cloud-based system. HMIs can be configured with sufficient storage to make this possible. This architecture also adds a level of robustness to safeguard data in the case of communications problems.
For an HMI to be considered as a datacentric platform, it must be able to handle data in a persistent manner and not in a transient fashion. Therefore, data-system design now becomes a factor in the platform implementation.
Forwarding and Pre-Processing Data
Part of the evolution of processes and machine control is the expansion of available data. Beyond improving performance, there are many other reasons why specific data may need to be accessed and processed. For example, government regulations and safety requirements can drive what data needs to be monitored and stored.
Some data points must be allocated as real-time only, and others may need to be pre-processed or otherwise filtered for storage. The latter type of data often can use a slower network to limit required bandwidth utilization.
One option for HMI data handling is to collect and store all possible raw data. Users may not know at configuration time just what data will be relevant for later analytics, so future needs can be addressed by storing and forwarding all collected raw data to a local database or to the cloud. Future machine learning and artificial intelligence initiatives will require massive amounts of raw data to create insights. Carefully designed HMIs can still handle this raw data, but store it and forward it in a less-than-real-time process to balance networking demands.
Sometimes it isn’t appropriate to transmit all possible connected and derived data values to higher-level systems at full fidelity. Loading up networks and consuming expensive historization licenses and server resources doesn’t always make sense. In these cases, a good solution is to pre-process the data in the HMI so only the useful results are communicated. This pre-processing could include level filtering, totalizing, reporting upstream by exception, and creating derived values such as overall equipment effectiveness (OEE).
Today’s HMIs are changing the experience of developers and end users in several ways. New IT-capable and cloud-friendly protocols such as MQTT and AMQP are readily incorporated in HMIs, allowing them to reliably communicate with supervisory systems, even through intermittent or low-bandwidth connections.
It is important to note that an HMI can be a hardware/firmware combination with local connectivity, or a software solution running on various levels of hardware with diverse types of connectivity. HMIs can be hosted on PCs, edge devices, centralized servers, or hybrid combinations of these—providing modularity and design flexibility.
The underlying operating system (OS) for any given HMI application may vary as an HMI’s host OS is no longer limited to Microsoft Windows. Open source OSs, such as Linux, are rapidly becoming acceptable in the industrial environment.
While HMIs have traditionally been local, the ability to locate them anywhere and push data to any cloud service such as Microsoft Azure or Amazon Web Services is not only possible but expected. Modern HMIs also use common interface platforms such as HTML5 to generate graphics and interface pages. Using these platforms, users will be able to view and interact with their processes and data anywhere with mobile devices, such as smartphones.
Driving Data Handling
Most important in our global environment is visibility into the process and data—data anywhere, anytime. Today’s HMI can meet these needs and more. Imagine an OEM deploying fleets of machines with global HMI access to provide support, determine OEE, and address maintenance issues. This type of service model will become commonplace as a result of the evolution of HMI software.
A modern-day HMI will still look and feel much like the HMIs of recent years, although there will be significant additions under the hood. The continuing advancement of HMI software applications provides access to data anywhere and anytime. With support for small-packet protocols, HMIs can talk directly to IIoT devices and IT-based protocols enable them to communicate with higher-level systems. OPC UA allows communication between an HMI and the other devices, requiring more bandwidth.
These new HMIs are becoming more data aware, more application diverse, and more process integrated and adaptive. They are poised to play an even more capable role within automation system architectures, with flexible integration with the cloud, and future machine learning and artificial intelligence becoming a common theme. EP
Marcia Gadbois is the President and General Manager, ADISRA, Austin, TX (adisra.com). An entrepreneur who grew a start-up from inception to a successful liquidity event, prior to joining ADISRA, Gadbois was a contributing author to the book, Client/Server Programming With RPC and DCE.