Editor’s Note: We sat down with Travis Cox, one of the Co-Directors of Sales Engineering at Inductive Automation to talk about HMIs, specifically software. While the hardware options for HMIs can be endless, the software in most cases is the "secret sauce" that brings it all together. See what Travis has to say about HMIs and the important software considerations for OEMs.
What factors must be considered to ensure a specific HMI software can work with the type of display panel used on the machine?
Historically, HMIs are all-in-one units consisting of hardware and software. Since HMIs are typically all-in-one units, OEMs are always looking for ways to make them more cost-effective, since they contribute a significant amount to the machine it is controlling. The tradeoff is a functional limitation in the software to achieve a balance economically. Most of the time, users view HMIs as isolated and independently managed devices. If these HMIs were to fail, a user would have to replace it with the same all-in-one unit, restore the project, and manage it independently, which can be costly and time-consuming.
OEMs are now looking towards a decoupled approach, where they can get a relatively inexpensive panel PC or touchscreen computer and pair it with the latest and greatest software. More importantly, software that has management services built in allows a user to centrally manage HMIs by checking health and diagnostics, synchronizing projects, and performing periodic remote upgrades. In this scenario, if the HMI fails, a user can install a new panel PC of any brand, install the same software, remotely send down the application, and be up and running in no time. It is a much simpler approach and much more economical.
OEMs are now starting to look to add more functionality without incurring a higher cost. Old HMIs just simply provided status control. There is no history, there is no alarming, but because users are becoming more sophisticated, thus more data is required. Users want to integrate that data natively within the rest of their systems, and technology based on open standards can make that happen. Users want to be able to have local HMI functionality but also want to connect directly to the rest of their plant and access the data remotely.
I think one of the things that all OEMs are looking to incorporate is MQTT. As an example, a user can plug in a panel device, get local data locally on that panel, but also have that data published automatically into the corporate infrastructure. Users can now do whatever they want with that data. A user is not locked into a proprietary solution that they aren't able to access.
Beyond providing visualization of the control system, what value-adds can HMI software be used to bring to an OEM’s customer?
Some value-added features can include the ability to have history and trends and the ability to analyze that data. Other features include alarming and being able to connect that data to the rest of the infrastructure through MQTT. OEMs can still look at reducing costs by providing limited features to the HMI, but give customers the ability to collect data from the HMI.
What developer tools should be supported by HMI software to make it easy to design and connect the interface?
The development environment should be included with an HMI. It shouldn't be separate, meaning that a user would need to download the development environment separately and potentially license it separately to be able and go in and connect to the HMI and configure it. It should just be a native part of the HMI. For example with Ignition, every single one of our installations has the Designer included because it's important to have that. You also need to have the ability to connect to a central management system. Rather than having several hundred isolated HMIs, you can centrally manage them. For example, with Ignition you can use the Enterprise Administration Module (EAM) to centrally manage hundreds of HMI.
You can also have HMIs operate independently if the network goes down so that operations can still continue. But having a centralized management system can help with scalability and maintenance. I think having a development environment that's also intuitive and easy to use, doesn't require a lot of coding, and that is drag-and-drop is quite powerful. Having the ability to connect to a centralized management type system to make area-wide changes is powerful as well.
Are the key capabilities of HMI software for OEM purposes changing as manufacturers become more connected, or are the requirements largely the same as they were a decade ago?
For the most part, requirements are relatively the same. Currently, customers would much prefer to have data on an HMI or device sent up to the OEM and have the OEM monitor that information and be able to tell them when things are going wrong. The idea of the service that the OEM could also provide to the customer to monitor that equipment for them means that they need to have the ability for MQTT; for example, to send data from that device up to their cloud infrastructure to be able to take advantage of it.
There are hardware companies that sell sensors and devices that are capable of publishing data to a cloud via a protocol such as MQTT. These companies sell a service where they are able to monitor the devices and provide customers with an interface to see and use the data. For customers it's a big win, getting data at the local HMI as well as getting data through a service. They have peace of mind that if something was to go wrong, the OEM is able to help them understand what to do and how to fix it. Hardware vendors know their equipment better than the customer and can build models and machine learning algorithms around their equipment. I think we will see a lot more of machine learning and analytics, machine learning, in particular, being utilized more from an OEM perspective because they have that capability and they know their equipment much more.
How can OEMs best position the value of HMI software featuring remote access capability to satisfy end user concerns about this type of connectivity?
The value is based on the balance between remote connectivity and security. When remote access is granted to an industrial system there needs to be justification for it and there is buy-in from the IT department. Organizations need to be transparent about what's going on and how systems are connected. There is a high demand for using encryption and the latest security models. With MQTT, there is a lot of security around that in particular. You have customers wanting to know if their data is isolated from other customers that are going to the cloud. Customers can get a bit scared about allowing access data to the cloud. OEMs have to demonstrate that security is a big focus that they take seriously. Customers want to know that they have encryption, that they have isolation, and that an application uses multi-factor authentication to verify a person’s identity before access is granted. If you look at all the things we use in our personal lives like Samsung with their smart things, or Nest or Ring. These things are all connected to the Internet and there's a lot of concern about security. Things like Ring or Nest and similar companies really take security very seriously. The big thing is to really understand and show that there is balance and things are not done haphazardly.
When data leaves the customer's premise, a vendor has to be able to ensure that there is security. Customers are not necessarily in control of that or understand what that looks like exactly so vendors need to provide tools that a customer can use internally and have security as a focus because the networks are more connected internally now. This has to be something that can be updated and managed that can also be secure as well.
