Have you ever wanted to buy a particular component for your automation system, only to find out its communication options didn’t mesh with the rest of your system? Perhaps you had found the perfect motor drive, but its Ethernet port only supported Modbus TCP, and you needed it to talk EtherNet/IP. Or maybe a weight controller you really wanted to use had a serial port but didn’t support Modbus, which would have meshed perfectly with your PLC.
To understand why these issues exist and how they could be addressed by vendors to your benefit, let’s look under the hood of automation components.
When a vendor designs a component, let’s say a motor drive, they need to decide what communication ports it will have and which protocols will be supported on those ports. The vendor wants to have as few ports and protocols as possible to keep costs down and to ease ongoing firmware maintenance, which is required as protocols are updated. But machine and robot builder OEMs buying these components want to have support for as many protocols as possible to make sure the communications they need now are in place and to provide flexibility for the future.
Another issue for many OEMs is the limited functionality of the operator interface provided on some automation components. The display hardware is in place to provide a full-featured operator interface, but the vendor’s built-in graphics are limited and hard to work with. Once again, the vendor is trying to keep costs down by limiting the development costs but in the process alienating existing and potential OEM and other customers by providing only a rudimentary operator interface (Figure 1).
Many OEMs work around these problems by adding stand-alone protocol converters, using a PLC or stand-alone HMI to convert protocols and using the stand-alone HMI to provide a higher level of operator interface. These workarounds address the issues but add cost and complexity.
Figure 1: PCs are typically used as the HMI development system, with compiled applications downloaded to targets such as another PC, an embedded HMI with an integral display or an automation component.
A better solution would be for automation components to provide support for many more protocols, along with a better operator interface. And because OEMs are under cost pressures, they need their component vendors to provide these features at little or no additional cost. Is it possible to square this circle?
More features, same cost
Advances in electronics are allowing many vendors in the commercial world to add more features while maintaining or even lowering price points. Smartphones and tablets are good examples. Many industrial automation component vendors are doing the same, albeit not always as quickly as their commercial counterparts.
But vendors can make product improvements by adding more communication options and improved operator interface functionality to their components by taking advantage of electronic advances coupled with new embedded HMI software.
Most smart automation components, like drives and stand-alone controllers, have more than enough processing power and memory to provide the real-time control functions that are at the heart of their devices. Much of the leftover processing power and memory is used to host the custom code required to provide the required connectivity and operator interface functionality.
This excess processing power and memory could instead be used to host embedded HMI software, provided the compiled HMI runtime software doesn’t require too much in the way of computing resources, and provided it’s easy to use.
Many HMI software suppliers make two versions of their software, one to run on PCs and a second and more compact version to run on embedded platforms with integral displays. So, it’s not much of a stretch for these suppliers to make a third version of their HMI software, one still more compact version designed to run on smart automation components and provide enhanced connectivity and operator interface functionality. This third version is what is referred to as “embedded HMI.”
This approach allows the automation component vendor to provide more connectivity and operator interface features without incurring the cost and time required to write, test and support custom code. The vendor can in turn pass on the savings to the OEM customers following these steps.
Most PC-based HMIs support hundreds of communication protocols and also provide the means to create operator interface screens. Embedded HMI software works in a similar manner, with a few key differences.
The development system hardware in both cases is the same, just a PC. But, whereas the runtime target platform for PC-based HMI is another PC or an embedded HMI platform, the target platform for embedded HMI is the automation component.
Because the automation component has much less in the way of computing resources than a PC or an embedded HMI platform, adjustments must be made. The operating system won’t be general purpose like Windows but will instead be designed and configured for a specific purpose. Microsoft, Linux, VxWorks and others all provide embedded operating systems for these types of applications. Unlike PC operating systems, embedded operating systems are customer-configured, with only the parts of the operating system necessary for the particular application downloaded to the target. This keeps them compact and reduces the need for extensive computing resources on the target platform.
In a similar manner, the embedded HMI software itself is a condensed version of its PC-based or embedded HMI counterpart, designed to run on an embedded operating system and consume a minimum of computing resources.
The automation component vendor first needs to make sure the component is compatible with the embedded HMI software in terms of the operating system, available computing resources and other specifications. If so, the vendor loads the embedded HMI development system software on to a PC and then configures the software application to provide the desired features.
Once configured, the application software can be tested on the PC using a feature that emulates the target platform. After testing, the application is compiled and downloaded to the runtime target. With some software, there’s no need to compile until downloading to the target, so the project stays platform-independent until the download step.
As with any software, maintenance and revisions will be required, and these will be provided by the HMI software supplier to the automation component vendor. The vendor will in turn update the embedded HMI software in the components as needed.
From a machine or robot builder OEM perspective, the whole process is transparent. The most important change for many OEMs will be the greatly expanded universe of connectivity options, from a handful to hundreds. The most visible change will be the operator interface, which can now more closely resemble the advance functionality offered by stand-alone HMIs.