Deploying HMI functionality in near-edge devices for IIoT connectivity

Many manufacturers have created well-developed core-functionality for control and monitoring which is embedded in their special-purpose controllers, smart valves, meters and other near-edge devices. These intelligent devices typically connect to a programmable logic controller (PLC) or other centralized controller to pass data back and forth, and the controller often connects to a PC-based human machine interface (HMI). The HMI is the gateway to higher level computing platforms such as SCADA systems, corporate databases, ERP systems and the industrial Internet of Things (IIoT) as it possesses the required Ethernet ports, protocol support, data storage and data handling functionality.

These near-edge devices have intelligence embedded, and this is often the manufacturers’ core intellectual property. For example, a temperature controller reads temperature, executes PID loops and monitors alarm set points (Figure 1). It would typically connect to a centralized controller or an HMI via a serial port and a simple protocol such as Modbus, or via Ethernet.


Figure 1. Near-edge devices, such as this temperature controller, typically have sufficient onboard computing resources to host an embedded HMI. (Source: AutomationDirect)

Another example of a near-edge device is a power meter, which senses energy use via current and power transformers and translates this data into power information, which could then be sent to a centralized controller or HMI.

As the intelligence of near-edge devices increases, a centralized controller and HMI may not be needed for connecting to higher level computing systems and the IIoT in all cases. These near-edge devices are already handling the required real-time control and monitoring functions in their embedded platform operating system such as Linux or VxWorks.

What many of these devices don’t have is a way to get information directly to higher level computing platforms and the IIoT, bypassing the centralized controller and HMI. To implement this advanced connectivity, data collection and related functions can often be embedded directly in the near-edge device (Figure 2).


Figure 2. Adding an embedded HMI to a near-edge hardware device enables connectivity to a wide variety of other computing platforms, often via the Internet. (Source: InduSoft)

Advantages of Embedding the HMI
The advantages of this approach depend on the application. In some instances, the near-edge device could use its embedded HMI to replace the PC-based HMI for the entire machine. In other applications, the near-edge device could perform dual connectivity functions, connecting to a centralized controller to exchange real-time control information, and connecting to higher level computing platforms directly to exchange data needed for analysis but not real-time control.

In either instance, the main advantage is the built-in software drivers in the embedded HMI. Near-edge device manufacturers no longer have to create and maintain a software driver for each of the hundreds of centralized controllers, PC-based HMIs and higher level computing platforms on the market—but can simply load embedded HMI software onto their devices. Near-edge device manufacturers also don’t need to write code to create graphics for local display on their devices, as the embedded HMI can perform this function through simple configuration steps.

The result in much faster and cheaper development time for near-edge device manufacturers as custom coding is replacing by software configuration, with the compiled configuration downloaded to the device.

How to Embed HMI Functionality in Near-Edge Devices
Near-edge devices have the ability to do more than just perform their embedded control and monitoring functions. With the right software embedded, these devices can provide data collection, data storage, connectivity to higher level computing platforms, and local or remote operator interface—creating an onboard, embedded HMI. Unlike a PC-based HMI or an HMI hosted on a dedicated platform, each of which has their own integral display, operator interaction with this embedded HMI can occur in two ways:

  1. Through an integral display, providing the near-edge device has one
  2. Through the higher level computing platform(s) to which the near-edge device is connected

In most all cases, the near-edge device will retain the capability to pass data back and forth to the centralized controller. But with an embedded HMI, it can also send data directly to higher level computing platforms and the IIoT, traditionally a PC-based HMI task.

As the amount of available computing resources in near-edge devices grows due to advances in processor power and memory chips, the main issue for adding this embedded HMI capability to near-edge devices is software development. Custom coding can certainly add the required capabilities, but this is only feasible for devices with very high annual unit sales as software development, testing and maintenance costs are substantial.

Another issue with custom coding is the requirement to write drivers to communicate with the wide variety of centralized controllers and HMIs on the market, as well as the different types of higher level computing systems. A third issue is maintaining all of these software drivers through every firmware revision of the controllers, HMIs and upper-level computing systems to which they are connected. Most near-edge device manufacturers respond to this issue by only supporting a few communication protocols through their serial port and Ethernet port. This simplifies their coding and maintenance requirements, but constrains the use of their products.

Next page >>

Many near-edge devices have very rudimentary operator interface functionality, although the device’s display is often capable of much more. The problem is the custom coding required to create sophisticated displays.

An alternative to address these issues is to use off-the-shelf software to add the required embedded HMI functionality, such as InduSoft’s IoTView, or other similar products. These PC-based software development environments provide more of a “drop-in and done” solution than custom coding, reducing time-to-market and development costs. These solutions also typically include hundreds of drivers to connect to centralized controllers and HMIs, and to higher level computing systems. Embedded HMI solutions also have very powerful graphic configuration functions built-in along with extensive object libraries.

Embedded HMI software must have a compact footprint and be able to run on multiple operating systems to permit downloading and execution on a variety of near-edge devices. Assuming the selected product has these features, here’s how to add it to a near-edge device. The implementation details shown in the Table are for IoTView, but similar products will have many of the same steps.

Table. Steps for Implementing an Embedded HMI

  1. Identify the target near-edge device processor type and operating system
  2. Configure the target device’s graphics and communications functionality on the PC-based development platform to create the application
  3. Test the application on the development platform
  4. Download the application to the target
  5. Connect internally to the target device’s internal data sources
  6. Connect externally from the target device to other computing systems
  7. Maintain the embedded HMI software: updates, bug fixes, revisions, etc.

Creating, Configuring, and Downloading
The platform for creating the embedded HMI application will be a PC-based development environment in most cases. When creating the project, the developer will have to know or decide on the near-edge processor type (ARM, x86, etc.) and operating system (Windows Embedded, Linux, VxWorks, etc.). This will allow the developer to choose the right tools and compiler. In the case of InduSoft’s IoTView, there is no need to compile until downloading to the target near-edge device, so the project stays platform independent until the download step.

Configuring the graphics for local or remote viewing must be done with the user in mind. Creating the right user interface that includes the required information and is user friendly can ultimately make or break the overall product, is this is the first thing the user sees and is the main point of interaction with the device.

Too much or too little data are both a problem, so it is important to focus on what is important to view with a glance, a quick look or careful study. What is displayed depends on the device used to view the data and what information is important to the user. Graphic designs should follow common user interface practices as illustrated in Figure 3.


Figure 3: Configuring graphics for local display on the near-edge device, or for remote display elsewhere, is an integral and important step for any embedded HMI implementation. (Source: InduSoft)

Required communications from the embedded device to other platforms, such as a SCADA system via Modbus/TCP or EtherNet/IP, should be decided early in the project. It is important to carefully define the data the embedded HMI will provide along with what variables will be needed and the addresses where they will be stored. Keeping addresses contiguous and variable names (Tag Names) short can improve communication efficiency (Figure 4).


Figure 4: Configuring connections between the near-edge device and other computing systems should be done with simplicity in mind in order to enhance communication efficiency. (Source: InduSoft)

The PC-based development environment should allow for quick and flexible downloads to the embedded device as a complicated install process can drastically increase a project’s engineering development time. Using the Remote Agent tool included with IoTView allows for quick design changes and updates, and provides remote troubleshooting and testing tools. For example, it only takes seconds to move an object (button, text input or icon) from one place on the screen to another, not minutes or even hours.

Testing and Connecting
Testing from a development perspective and quality standpoint also needs to be considered at product conception. Can the embedded project be tested and vetted on a non-embedded device, such as a Windows PC? If so, simulation and logic testing can be done locally before sending files to the embedded device, reducing total development time.

The target device will typically have a serial or Ethernet port, or possibly a wireless connection option (Figure 5). If the embedded device includes a TCP/IP stack—then LAN, Internet, radio modem, cellular or even satellite connections can be supported.


Figure 5: The embedded HMI software development system should support a wide variety of communications options for connecting and downloading to the target platform. (Source: InduSoft)

One of the main advantages of an embedded HMI is the ability to send data directly to the cloud, a necessity for many IIoT implementations. Sending data to a cloud-based storage system such as an SQL database, a MQTT broker or a commercial data storage company such as Amazon will be greatly simplified with the built-in tools provided by most embedded HMI software products.

Conclusion
A near-edge device with an embedded HMI can make it much easier for device manufacturer’s to provide an advanced local or remote operator interface display, and to exchange data with other computing platforms. Off-the-shelf software is available to configure embedded HMI applications and download them to near-edge target devices. This is often a better alternative than custom coding to implement local display functions, and also to implement and maintain connectivity to other computing platforms.

Scott Kortier has over 28 years of experience including HMI/SCADA, Industrial PCs and technical sales. Scott is a graduate of Michigan Technological University and has developed hundreds of HMI and SCADA projects for the automotive and packaging industries and plastic injection molding machines.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.