How to Design and Deploy a Web-Based HMI Project - Part 1

What is an HMI?

As the name implies, a human-machine interface is a medium that allows operators, technicians, and supervisors to monitor and control industrial systems. This can include extensive monitoring dashboards for manufacturing areas in a plant down to the granular level of an interface used to control a plant asset such as an automated assembly machine.

 

Figure 1. An example of an HMI screen. Image used courtesy of Inductive Automation

 

Traditional Versus Web-Based HMI

Traditional HMIs have been solutions developed for local use only. This means that in order to control or monitor parameters on a plant asset, the individual needs to be physically present at the machine where the HMI is deployed. These HMIs are not connected to an internal company network, so there is no way to view or control the machine remotely.

The upside of traditional HMIs is a relative amount of security and simplicity. Authorizing who has access to the machine can be accomplished by tangible means such as door access card scanners and authorization to the operating system or local application tied to the machine. However, the downsides of this approach are numerous:

1. Visibility and data collection: with no network connection, data acquisition for SCADA purposes is restricted to manual downloads using portable storage devices. This usually produces disastrous results for SCADA and introduces security risks of malware distribution to the machine using USB drives.
2. Application management: any patches or software updates have to be performed on the local machine and may involve error-prone tasks of manually creating backup files, updating existing files, or adding new software dependencies altogether.

In contrast, web-based HMIs are a newer take on the traditional technology stack. HMI screens can be accessed by a client with a web browser given a URI. The individual does not need to be physically at the machine to access the HMI. The advantages of this approach include increased visibility and seamless data collection due to the connectivity of the HMI to the internal corporate network. However, more detailed knowledge surrounding networking and security best practices is required to ensure the integrity of operations.

 

How Can I Get Started With Web-based HMIs?

The two main options on hand are:

1. Purchase an out-of-box or Software as a Service (SaaS) platform such as Ignition by Inductive Automation
2. Build your own custom, internal end-to-end solution

Both approaches have pros and cons. We will pursue the custom end-to-end solution in this article series.

It should be noted that a custom approach is the heavier technical lift of the two and will require engineers that have strong software engineering capability yet understand or are capable of learning the business requirements. The delivery timeline with this approach will be longer due to the development time and breadth of technologies required. The costs with this approach are in the development labor and time as opposed to the licensing and training costs associated with the SaaS approach.

 

High-level Solution Overview

In this article series, we will explore a simplified web-based HMI solution. The solution will comprise the below elements:

 

Figure 2. Solution architecture for a simple web-based HMI. Image provided by the author

 

The technology stack includes:

• Edge computing layer
• Data middle layer (API Server)
• Back end database layer
• Front end web application layer

 

Edge Computing Layer

The beginning of a web-based HMI solution originates at the plant floor level. The hardware and gateway device are critical steps in the process. For this walkthrough, I assume there is a single read-only tag, Tag A, for simplicity. This tag is connected to an I/O module or gateway device capable of HTTP communication. One such example of a device is the Groov EPIC by Opto22, or industrial PCs capable of HTTP communication. Some PLCs also have this ability built in or enabled by add-on solutions.

 

Figure 3. Edge computing layer. Image provided by the author

 

In order to communicate and facilitate data transfer outside of the local machine network, the HTTP-enabled edge device will need to send an HTTP POST request containing a body of data. A programmatic example can be given with the example below using the Python requests library. The function of this code is to send a sample tag with data every 5 seconds to an API server. Comments denoted with the # character explain the process steps:

# Necessary libraries. Requests will require a pip install
import requests
from random import randint
from time import sleep

APIServer = "WHAT IS THIS?"

# Scanning/refresh rate behavior created by while loop
while True:
    # Randomly create our read-only Tag A
    tag = "Tag A"
    tagValue = randint(1,100)

    # Construct a JSON payload body for Tag A
    payload = {"tagName": tag,
               "value": tagValue
    }

    # Send the payload via an HTTP request to the API Server
    response = requests.post(APIServer, json = payload)

    # Handle the response from the API Server
    if response.status_code == 200:
        print(response.content.decode('utf-8'))
    else:
        print(response.status_code, response.content.decode('utf-8'))

    # Time delay of 5 seconds
    sleep(5)

 

In order for this script and protocol to function, we have to send the POST request somewhere in order for data transfer to occur. This “somewhere” entity is an API server in the middle layer of our solution. At this point in the project, the API server is not defined and we presently have no way to transfer our payload of Tag A data outside of the local machine network on the plant floor.

Our next steps continue in Part 2 of this series.