![](https://static.isu.pub/fe/default-story-images/news.jpg?width=720&quality=85%2C50)
7 minute read
How to Select HMI Software
In addition to assessing developer tools and changing user requirements, OEMs must also now take into account remote access concerns when deciding which HMI software to use.
Marc Andreeson, co-founder of Netscape and the venture capital firm Andreesen-Horowitz, once talked about “software eating the world.” He was referring to the criticality of software to modern businesses and software’s role in overturning established industry structures. And it’s just as true for HMI software.
That’s why the decision-making process surrounding HMI software options is so critical. And the first step in this process is making sure the HMI software you want to use can work with the type of display panel used on the machine.
Historically, HMIs have been all-in-one units consisting of hardware and software. As a result, OEMs are always looking for ways to make them more cost-e ective. The tradeo is a functional limitation in the software to achieve a balance economically. That’s why more 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.
In some cases, it may not be easy for OEMs to ascertain beforehand the number of required displays and the complexity of each. This issue can be addressed by selecting a supplier with one HMI programming software package that works with their entire family of displays.
Also, instead of buying the HMI hardware up front, and possibly choosing the wrong model, it may better to select the programming software you prefer first and create the displays as needed. OEMs can work with a local distributor and download the displays to di erent target HMIs to make the best selection.
DEVELOPER TOOLS
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 to connect to the HMI and configure it. OEMs should also provide a way for users to connect the HMI to a central management system. That way, rather than having several hundred isolated HMIs, the user can centrally manage them.
Another option is to set up the HMIs to operate independently if the network goes down so that operations can still continue. However, having a centralized management system can help with scalability and maintenance. Having the ability to connect to a centralized management type system to make area-wide changes is powerful.
The information technology (IT) side of an HMI system, including mobile apps, email, and access to files in the cloud or on a network, are all common tools used every day in modern Internet of Things systems. An HMI must have these features to ensure data and information is available locally and in a cloud-based platform.
Mobile apps for Android and iOS devices provide two-way access to HMIs via Wi-Fi, allowing users to monitor PLC parameters or change set points or other variables. These apps provide dialog interfaces to monitor or control most data variables.
These apps should also include features to limit the parameters monitored and controlled. Some of these apps can also upload and download programming software or even delete data from internal memory or external memory devices such as a micro SD card. Because of the increasing need for this type of connected access, cybersecurity practices, such as limiting users and including a robust username and password, must be followed.
Good mobile HMI apps can include more than data logs, pictures, and similar files. HMI screen shots, alarm log files, and recipe files can also be uploaded and downloaded. In some systems, if an HMI is connected to a PLC, the HMI can download an updated PLC program, eliminating the need to use programming software to complete the task.
CHANGING USER REQUIREMENTS
While the IT side of the system is critical to getting data and information to the right places and people, the operational technology (OT) side plays an important role in controlling the machine or process. Because HMIs communicate with controllers, HMIs are often the first devices to touch the data that comes from a sensor, a digital
input, or an internal variable in a PLC.
An HMI communicating to multiple industrial protocols simultaneously is a requirement in many automated systems. Often, multiple controllers from multiple manufacturers are used on a single system. There are more than 100 PLC protocols, and support for all of them sets an HMI apart from its competition.
With this in mind, the HMI should be selected to meet all communication requirements. Serial and network drivers to communicate with di erent manufacturers of PLCs will save time and money.
While using an HMI as a communication gateway may not o er real-time control data update speeds, it can still pass data between devices that can be used to make control decisions. HMIs can also act as a data concentrator when communicating with multiple controllers and then feeding that data and information to the IT side of the system.
REMOTE ACCESS CONCERNS
Older HMIs simply provided status control— no history and no alarming. Today, more 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.
This is driving more OEMs to look at incorporating MQTT. With MQTT, 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. This allows users to do whatever they want with that data.
One simple and cost-e ective way to do it is using HMIs with a built-in web server. The web server provides this remote access functionality without the need for additional software or hardware.
The web server in the HMI is accessed using any device with a web browser. Accessing the HMI using this method gives a user the same functionality as if they were standing in front of the HMI on the factory floor. Troubleshooting and maintenance of a system is possible any time and from anywhere, without the time and expenses of travel.
Options in these remotely accessible HMIs include a remote control page, remote monitor page, and a system information page. Simple configuration tools allow a programmer to select the functions that appear on these pages. However, limiting control and monitoring functions available to a remote user should be considered to ensure proper cybersecurity of critical applications.
Typical network configuration of HMIs with web servers includes a local network with Ethernet communication and suitable industrial protocol. The HMI connects to controllers and to local and remote web browser terminals. Proper cybersecurity practices should be followed when using the web browser terminals on external networks to access the HMI on the local network through the local network's gateway/router and firewall.
The ultimate value of remote access for the user will be 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 should be 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. OEMs have to demonstrate that security is a big focus 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.
When data leaves the customer's premises, an OEM has to be able to ensure that there is security. Customers do not necessarily understand what that looks like, so OEMs need to provide tools that a customer can use internally.
ABSOLUTE ENCODERS WITH IO-LINK
Smart Encoder Ready for Industry 4.0
Simplify Your Communications System
Magnetic Multiturn Sensing Without Gears or Batteries
Perfect for Factory and Process Automation Applications
Condition Monitoring via Vibration and Temperature Sensor