Welcome again to the world of industrial software. This article is a collection of thoughts to provide practical exposure into the concept of HMIs, and why they are important. We will also cover important concepts that apply to the data performance of industrial software in general. The article will first go through the basic concepts around HMIs, their use cases, and how they work. From there, we’ll dive deeper into real world design and implementation considerations, that come along with embedding HMIs in industrial environments.

The basics

HMIs or Human Machine Interfaces are popular pieces of software, utilized by all classes of users in an industrial software environment, this includes factories, power plants, water purification stations…etc. HMIs are the real life counterparts of those huge screens you see in action movies, when an operator is monitoring the electrical power of a city before a hacker interjects and causes a blackout of the city lights.

So what are HMIs? HMIs are pieces of software that carry out two main tasks in an industrial environment.

First: they provide a visual representation of your industrial data. You can then use this visual interface to understand exactly what’s happening in your industrial environment.  For example: if you are looking at the HMI screen of an oil rig in the middle of the ocean, you’d be able to know the different pressure readings on pipes all over the rig, you’d be able to read the temperatures at the critical points on the pipes…etc.

Second: HMIs -if given proper permissions- allow you to control your industrial environment. So going back to the oil rig example, an HMI screen is how you’d send the commands to shut down valves and open others on your pipes to direct the oil flow throughout the facility.

So how does an HMI achieve those two tasks? It does it by maintaining connections to the various sensors and control devices in your industrial network. This is typically done via a sophisticated combined software and hardware infrastructure, where networking devices like routers or switches pass data between industrial software and industrial control devices and sensors. This combined software and hardware infrastructure is usually labeled SCADA.

Beyond the basics

Now that we understand what HMIs are, why they are useful, and how they work; it’s time to look into some real world challenges that come up when we decide to utilize HMIs.

HMI implementation challenges

The concepts of what an HMI is, and how it works might sound simple. However, in real life, it’s not that straight forward. We’ll cover some of the challenges that experienced SCADA engineers think about. Consider the following three questions:

How big is your industrial environment?

Consider the example of an oil rig again. Before,  we put ourselves in the shoes of an operator responsible for the rig. Now what if -this time- we put ourselves in the shoes of a staff engineer who is responsible for all the rigs that belong to his organization. The amount of data to process here could be massive if -say- we control hundreds of rigs.

How often do you need to ask for data? 

Not all industrial sensors are smart; they won’t notify you whenever a value changes. That means you have to make a decision on how often to “pull” for data in order to build a realistic picture of your environment. For example, let’s say you have a simple sensor that monitors pressure on a pipe. If we ask for data every half an hour, and the pressure changed 1000 different times within this half hour, we won’t build a real picture of what’s happening if we just read the value at the end of the half hour. What if there is a big block in the pipe causing random pressures to form? Not reading data at reasonable frequency causes us not to identify the behavior.

At the same time, if we ask for data 10 times each second, our networking infrastructure might break from overwhelmed bandwidth. So we have to find a good realistic frequency for our data polls. Someone might ask, why not just use more sophisticated sensors, protocols, or monitoring devices. The answer is simply because they don’t come cheap!!

How do you handle different groups of users? 

As mentioned earlier, different classes of users utilize HMIs. So what happens if you have a director, a staff engineer, and a field technician needing HMI access?

Let’s go  back to the oil rig example. The director will probably care the most about readings of the overall gas flow from multiple rigs in order to build an idea of the production rate of each rig. She or he won’t be comfortable sending commands to the control systems on the rig (unless it’s a startup!).

The staff engineer on the other hand, would want to see readings from multiple rigs in order to build an idea about the performance of the rigs. They would also not shy away from sending commands to control the rig. On the other hand, a field technician who lives in one of our rigs would only care about a very detailed view of the rig he or she is trying to troubleshoot, and it won’t make sense to give him or her access to control other rigs elsewhere in the world.

Industrial software design considerations

Now that we defined some practical challenges, let’s cover the thought process involved with addressing them in a real industrial software environment. How to do the design differs from one HMI vendor to another, however the concepts and challenges stay true across all vendors.

Let’s start with the first question: How big is your industrial environment? This consideration is obviously more applicable to larger industrial environments, than smaller ones.

An example of a small industrial environment is a single small factory, where all the sensors and users exist in the same facility. In this case, there is little chance we’d have too much data loads or infrastructure complexities. Chances are: we’ll install the HMI software, then connect it to some OPC servers or device drivers for our sensors.

On the other hand, if our industrial environment is a large one, like the case of distributed networks of offshore oil rigs around the world. Then, we have to consider the networking bandwidth load to collect all this data in real time. More often than not, it becomes less sustainable as our organization grows, and more rigs are added. There are multiple approaches to address this problem, here is the thought process involved:

1. Don’t push every single piece of data collected in all the rigs to a single HMI. Instead distribute your data visualization, by using local and remote HMIs to represent your data. Study your data, and decide which data needs to be sent to a central HMI that monitors all the rigs combined, and which data only need to be viewed on a local HMI at each rig. For example, data that represents the total production output of each rig will for sure be valuable to engineers who live on the rig, as well as engineers who operate from the head office. On the other hand, data that reflects the pressure points of a small pipe some floor on the rig may be more relevant to engineers on the rig than an engineer who works at the head office.
2. If the data you need pushed to a central HMI that monitor all your rigs is still way too much, then you need to consider load balancing. Load balancing is the idea of distributing the data load among multiple servers or networking devices. There are two main types of load balancers: hardware, and software load balancers. Which type to utilize relies on your  budget and project requirements.

Now let’s go to the second question: How often do you need to ask for data?

The technical term for the frequency of data reads is typically called a sample rate.

The consideration is also important to address whether you are implementing an HMI or a process historian or any other piece of industrial software that is expected to work with data.

In real life, there are two types of reads in an industrial environment:

• A pull (or demand) read: which is the type mentioned earlier in this article. A pull read is a “forced read” that happens every predefined frequency
• An unsolicited read: this type happens more often with smarter sensors or smart software device drivers. In this type of read, you “subscribe” to some data points -like, for example, pressure A at pipe 1 or temperature B at pipe 2- in order to portray your desire to be notified whenever the values change on those points. After you subscribe, you get the new values whenever pressure A or temperature B change

In fact , the concept of device reads in an industrial environment go beyond the above two types, because there are other factors to consider. In the next couple of paragraphs, we’ll discuss some important considerations to think about in the world of industrial environments.

What if the unsolicited reads happen too often, and we don’t need all this data? In this case we can set our sample rates to be more compatible with our needs. In most software systems, if you set your sample rate to 3 seconds, but the value changes 5 times in those 3 seconds, you would only see the last value observed in the 3 second time frame. This helps get rid of unneeded data that would load up your hardware and software SCADA systems.

Let’s say we are using either a pull read or unsolicited subscription, but the new value of the monitored data point is just too close to the previous value to make any difference in our analysis. For example, the previous value is 33, while the current value is 33.0001. In a well designed industrial environment, we would need to ignore those values, so that they won’t clog our HMIs or our industrial historians. To achieve that, we need to set ‘deadbands’. In the world of HMIs and industrial historians, a deadband is basically a value that defines a range between the last observed value and the current observed value, where we can safely ignore the current observed value. Deadbands are used to ensure we don’t record too many unnecessary data values that are too close to the previously observed values.  They make significant difference in performance in industrial environments.

Now, it’s time for the final question: How do you handle different groups of users? 

Like the previous consideration, this consideration is important to address  for any piece of industrial software that is expected to work with data.

Industrial software like HMIs and process historians hold very critical data  for the organizations that make use of them. HMIs in particular get more critical, because ,additionally, they typically allow users to send commands to industrial devices, effectively causing lasting effects. Because of this criticality, it’s not only important to protect the software from external access outside of the organization, but it is also important to provide selective internal access based on roles of employees inside the organization. In other words, a staff engineer who manages all the rigs should have different access than a junior engineer who is responsible for a single section inside a rig.

Modern HMIs typically provide protections via several approaches.

• The easy approach is to create custom internal access lists. What this means is that inside your software, you define a list of users, their roles in your organization  and what they are allowed and not allowed to do or see in the HMI. This is typically provided as a feature by HMI and process historian vendors. The disadvantage of this approach is the fact that it creates an isolated access list inside the software, which is isolated from the organization IT infrastructure. This means that if an employee leaves the company or get promoted, we have to reconfigure the custom access list, in addition to the IT permission lists like active directory, to reflect the new changes
• The more difficult, but more efficient approach, is to integrate the industrial software with the IT infrastructure of the organization. This is also provided as a feature by vendors. The IT infrastructure -like active directory for example- would host the list of the company employees, the security groups they have access to, and their permissions. With this wealth of information about potential users of the HMI, we can craft a map for what would be permitted or not for each user. The advantage of this feature is that whenever a new employee joins the organization, or an existing employee leaves the organization, the HMI will open up access based on their IT permissions. We would also not need to recreate all the access permission information to create a custom access list

With this, we come to the conclusion of this article. It took effort to collect my thoughts around it and finish it. Hope you found it useful 🙂