A Control Design reader writes: The human-machine interface (HMI) on all of the packaging equipment we design and build has traditionally dictated the software. With customers continuously asking for more interoperability of all components, we’re investigating open-source HMI software. What are the advantages and drawbacks? And what sorts of additional hardware might be necessary?
Answers
Defining HMI: Is it still hardware?
Not long ago, before everyone had smartphones in their pockets, an industrial human-machine interface (HMI) may have been the only interaction someone would have with a touchscreen device. That is crazy, right? In those days, an HMI was strictly a piece of hardware, connected via your favorite fieldbus to a PLC.
Also read: The transformation of HMIs
Development on both ends were handled via proprietary software, and engineers became experts, as well as very opinionated, about how to properly map data registers.
These days an HMI can take many forms. Many traditional HMIs are out there, but the demand for modern interfaces, interoperability and portability means that the dedicated HMI model is being threatened.
Many users prefer the familiar interface of a phone or tablet along with the smooth aesthetics of contemporary application design. If you are a facilities operator, you need the HMI to be intuitive and efficient; if you are an OEM, the HMI might be the most frequent touch point to your customers and the face of your machine.
So, why open-source? Is it because it's free? Nope, well, maybe sometimes.
First, let's define the term “open-source.” Simply put, open-source is software for which the original source code is made freely available and may be redistributed and modified.
A popular phrase in open-source is that it’s more like “free speech” than “free beer.” This is one of the drawbacks. It represents freedom and access. It is not free of cost because the responsibility of using open-source tools transfers the responsibility to the developer tasked with implementing them. This requires understanding, experience and time. This can be expensive; most times it is not; and support can be found in the deep sea of passionate communities.
Many of the technologies that power the world of Web applications, super computers and even the Internet itself are open-source. This includes massive development efforts such as Linux and Node-RED. Redhat, an open-source Linux distribution and commercial product just became the largest software transaction when it was acquired by IBM for $34 billion.
Platforms like Node-RED are changing the way we think of user-interface development. It has given access to so many users who want to use the most current tools to build their machine visualizations but lack the skills and experience to write HTML5 or typescript.
Node-RED is a low-code environment that makes use of Node.js, a runtime based on JavaScript programming language. This environment makes use of HTML5, Vue.js, React.js. It is so easy to use that developers can go from first interactions to proof of concept in a matter of minutes—yes, I mean that literally.
The real power in open-source is in its tendency to work like building blocks. For example, visualizations require data, and that data needs to be stored somewhere. That data needs to be transported, as well.
There are a whole host of tools to use, such as Eclipse Mosquitto, an open-source message broker that implements the message-queuing-telemetry-transport (MQTT) protocol, and InfluxDB, a time-series database; all run on Linux and work in concert to build amazing interactive industrial interfaces.
Couple this with easy-to-configure dashboarding tools like Grafana or Chronograf; all are extensible and make available contributions from massive communities that make use of them.
Maybe the most important evolution to HMI platforms is the introduction of Linux, which provides an important canvas to create a diverse and highly functional interface.
How do you get started? If you are already implementing devices with Linux and a browser, then you are ready get started right away. No other hardware is needed. Install Node-RED and begin building interfaces with a simple browser-based integrated development environment (IDE). Import dashboard nodes to add components to the Web user interface (UI), and you will be amazed at how quickly you will build interactive UIs. If your HMI has a browser, then you can point this to your Node-RED instance, and you may never look at closed-source HMI solutions the same way again.
Jesse Cox / senior application engineer for Linux and IIoT / Wago / www.wago.com
Differentiate your machine brand
What the reader is describing is all too common in our industry. Many HMI software packages offered in the market have a finite set of features and a closed architecture. What is shipped by the vendor is what you get—take it or leave it.
For machine builders who build machines similar to their competitors, the HMI is a major way to differentiate and brand your machine. Many times we see similar machine-builder OEMs using the same vendor’s HMI software, and, in most cases, the two OEMs’ HMIs look very similar because they both had the same finite toolbox to work with. This makes it very difficult for one machine to really stand out in terms of machine operator experience and functionality.
In this case, it would be very tempting to look at an open-source solution since open source promises the greatest possible flexibility. However, there are some drawbacks to the open-source approach, as well. The biggest is, if it comes down to the final weeks or days to finalize a new machine design and get it out the door, but there's a major problem with the HMI, you're then relying on the open-source community and your own internal development resources for fixes and troubleshooting. This may impact machine delivery times and increase overall costs to the OEM.
So, where's the happy middle ground between the closed-box HMI solution and an open-source wilderness? I would encourage you to do some HMI-software research and evaluations across the industry. There are vendors in the market that have built software products that address this exact machine-builder struggle and the limitations of their current HMI platforms.
I recommend you select an HMI platform that permits full flexibility for customizing, adding or creating new HMI elements for the toolbox, creating and implementing your own custom communication protocols, software connection protocols or database connections (Figure 1). Some modern platforms offer full multi-touch functionality, rich rendered 3D graphics capabilities, virtual twin capabilities and encrypted data transmission to the cloud. You can find this flexibility while still building inside a framework that is under continuous professional development, regularly adds new features and offers 24/7 expert support.
Daymon Thompson / U.S. software product manager / Beckhoff Automation / www.beckhoff.com
Nothing is without cost
There is no doubt open-source software and more specifically the Free and Open Source Software (FOSS) movement, have given automation professionals a lot of new options to choose from. But there are certainly pitfalls and drawbacks to be aware of when deciding on the right solution for you.
Not all open-source software is no-cost, and often the zero-cost solution can end up being the most expensive. Many companies have a hybrid offering with a community edition available for free and a more featureful version for some fee. Or they will offer support for a fee. Many of these choices are excellent solutions, but the company behind it has an obvious incentive to encourage users to migrate to the paid version. If the cost of the paid version is too much, in the long term it may be wasted effort migrating to the free version.
For solutions that do come at zero cost, and there are many amazingly useful and powerful examples out there, it is worth spending some time considering who is backing the project and why. And you need to take stock of just how “under the hood” you are willing to get.
When something goes wrong, you have no one, except yourself, with a vested interest in finding a solution. You will have to rely on internal resources or the community surrounding the project. Many of these projects have an active community ready to help, but some projects just fizzle out over time, in which case you have to maintain things yourself or endure the pain of converting to something else. These issues of course exist with closed-source projects, too. With a closed-source solution, there is no way to fix something yourself; you are entirely reliant on the vendor to provide an update. If you visit the source repository of many open-source projects, you will often find a long and scary list of bugs that need fixing. With a closed-source project there is no doubt that a similar list exists; you just don’t have access to it and have no possibility to jump in and fix something yourself.
Hardware is another trade-off. Closed-source software often locks you into a specific hardware vendor. With open-source solutions you can shop around, diversify your sources and potentially lower cost. However, you take on the responsibility of verifying compatibility. What operating system do you need? Are there drivers or software packages to install? Is the speed and architecture of the processor adequate? Using a closed-source solution that requires specific hardware takes some of the decision-making away.
Mike Sheldon / engineer / Maple Systems /Â www.maplesystems.com
Figure 2: Open-source software can provide more flexibility for hardware platforms or specialty equipment used in food-and-beverage approved devices.
Budget and development time savings
I can point to three advantages for open-source software on an HMI. First, and the most obvious, is that nearly all open-source software (OSS) is free and that leads into immediate budget savings for the user. Second, along the same lines of budget savings, is less programming/development time. Once the application is developed, it can be easily translated into different hardware platforms that share the same software. And lastly is the ability to select freely from several potential hardware platforms, opening the doors to a wider product range, where the user might be able to find a very specific piece of hardware that really fits perfectly to their needs, such as devices with IP67 or food-and-beverage-approved devices (Figure 2).
The biggest drawback to consider for an industrial HMI application is tech support. With licensed software, it is fairly common to have a direct point of contact for technical support with the supplier that developed the product. That supplier can expedite problems and solve any issues that arise during deployment, whereas using OSS might be more challenging to find one specific contact for support. Consider this point before making your purchase. Is it clearly outlined who will provide support?
Roberto Solis / product manager / Turck / www.turck.com
Open-source requires in-house expertise
The adage that a blessing can come with a curse sometimes holds true for open-source software. For all types of applications, including industrial HMI software, open-source software can offer advantages compared with using proprietary software, but users also need to be aware of the drawbacks before committing to an open-source approach.
Open-source advantages:
- Users are free to modify the source code, giving them complete flexibility to customize the application to the environment.
- Usually, any licensing and maintenance fees are lower cost than commercially available software.
Open-source drawbacks:
- Modifying source code requires expert skills.
- Users may need to pay for documentation, media and support.
- Users must be aware that there are different variations of open-source software licensing, and some are more restrictive than others. A careful software license review is needed to provide a clear understanding of what one can and cannot do with the open-source software.
- Maintenance costs may also be an issue because users are relying on the open-source community to support the software. In production environments, where the risk of business interruption is high, lack of immediate support could be a major problem. If the community is not supporting new operating systems, drivers, features, hardware platforms and security flaw fixes, then the responsibility for maintaining the software falls on the end user.
- Another significant concern is that open-source software has many options and comes in many different permutations. End users must establish a software standard to ensure that the entire company is on the same version so that it is easy to maintain the open-source software.
- Similarly, version control is another factor that should be considered with open-source software. New open-source software releases are issued frequently, sometimes on a weekly basis. Each new release must be tested with existing applications and hardware to ensure the solution operates appropriately. An additional task is verifying that the new version does not contain any viruses or malware.
- Another major open-source software disadvantage is the ever-present risk that the community stops supporting it or the maintaining company is acquired. CentOS is an example of this occurring. The CentOS community was originally led by Red Hat, and most of the CentOS work was performed by Red Hat employees. Red Hat was acquired by IBM on July 9, 2019. On December 8, 2020, Red Hat and the CentOS community announced the end of life to CentOS Linux. So, for anyone using CentOS, the responsibility for maintaining the entire product after this point fell to the end users.
In contrast with open-source, proprietary software has advantages, in that the vendor maintains the software and its integration with other software packages, such as databases. The vendor also has expert subject matter resources available to the customers such as training, support and consultancy. This is important for HMI projects where end users might need to engage additional support.
Figure 3: HMI software provides open flexibility for deployment and connectivity, but is offered under a model ensuring that end users are supported for technical and security updates.
Another proprietary software advantage is that vendors speak to a lot of customers and keep up on the latest software trends, so new features and requirements are regularly being added, which allows the software to constantly be evolving. For HMI software, this helps ensure that the most important features are always available (Figure 3).
Finally, a proprietary software vendor is responsible for supporting new operating systems, drivers, features and hardware platforms, and addressing any security issues. They are accountable to their customers to ensure there is an upgrade path forward to new platforms or added HMI software features.
Bruno Crepaldi / chief technology officer / ADISRA / www.adisra.com
Balance total cost of ownership
One of the key design elements is knowing what the end users are comfortable with. In many cases, our organizations want a particular HMI based on previously installed equipment or familiarity. This can limit the available options when considering open-source development platforms as most HMIs are purpose-built and require a specific, commercially available development platform.
When there is flexibility or requirements to use open-source development platforms, there are two key advantages: flexibility and licensing costs. Full control and configuration of the software is possible as the source code of the development software is available. A sufficiently skilled engineer would be able to create software tailored to a much more unique end-user experience or bespoke solutions for a customer request. Open-source software usually means no licensing costs for development software. This may be an advantage but would be dependent on the implementation. Most open-source solutions will require an inter-process-communications (IPC) centric solution, which may require additional equipment, such as uninterruptible power supply, data concentrator, hosts or screens, that would offset the savings.
For the developers and the end user, total cost of ownership (TCO) is always important to balance when considering open-source platforms. As with any open-source community development, there is a nice starting point to build upon new functionality and capabilities into the code for the specific application or use case. However, unless contributions are made back to the community, there is risk of compatibility issues with updates to the open-source environment. Furthermore, forking from the community puts a larger burden on the adopter to maintain and address issues with the starting point.
There is a need to consider whether an organization has the right blend of software and controls engineers to support the development and maintenance of a system, which can add up to a big expense in the long term. Getting a team trained and then appropriately staffed can take a lot of resources away from the development of the solution.
In addition to cost, there are a few other technical considerations including fault tolerance, security and additional software. Control systems tend to have high fault tolerance with ability to quickly replace hardware and redeploy applications where PC-based solutions are not so friendly. Most commercially available solutions come with cybersecurity certifications that open-source solutions cannot offer or may not maintain. This is particularly worth evaluating when handling data. Open-source software may not natively support required PLC communication protocols, necessitating additional software to translate this into a format that is supported. Generally, there is a cost associated with this software, which would be a per-unit cost.
Joe Ambrose / digital innovation program manager / BW Packaging Systems /Â www.bwpackagingsystems.com
Consider open-source project adoption
Evolving industry standards and new technologies are creating more opportunities for interoperability. As a technology provider, we too are constantly looking for ways to leverage technology partners and open-source projects to deliver value faster.
When considering any technology, it’s important to consider the trade-offs. This is especially true with open-source projects. It’s important to evaluate the benefits of the functionality with the risks of using an as-is code base of which you may have limited expertise. There are good examples of stable, open-source code libraries, such as MQTT, that have broad market adoption.
When considering open-source, you must ask if the available functionality will meet your needs or need to be extended. If it needs to be extended, ask yourself: Is the open-source well-documented, and do you have the expertise to extend it?Â
You also need to consider the licensing models. Some open-source projects require that any changes be contributed back to that open-source project. You should also consider the adoption or popularity of the open-source project. Open-source projects with limited adoption may be very slow to make any changes or improvements. Unless you are prepared to resource your projects to address these and many other concerns, open-source may not be the right approach, regardless of the functionality.
Steve Briant / visualization platform leader / Rockwell Automation / www.rockwellautomation.com
Testing and certifications for open systems
Open-source HMI software offers the ability of anyone to see and change the source code driving the HMI functionality. In theory, it would allow the machine designer, and even the customer, the ability to make changes to how the HMI functions and what features it might have.
Conventional HMIs typically have what is sometimes called a closed system. In a closed system, only the manufacturer of the HMI can modify the underlying source code and change features and functionality. The customer has a more limited choice of operating options vs. an open system.
While having the ability to change the underlying source code that makes the HMI function sounds appealing, there are good reasons that the majority of HMI being used today are closed systems. Open means that anyone with any level of training can modify how the HMI operates. That leaves open the chance for introducing low-level programming errors, function errors or malware.
With the open system, for the most part, functional testing, safety, approvals of function and any certifications will be up to the open-system designer. In a closed system, this is handled by the manufacturer of the closed HMI.
The best interoperability and security will be available by purchasing a system solution that includes the control system, HMI, I/O and other components from the same manufacturer. Full-solution providers will ensure best access to all of the features available from them. Intentional mixing of controllers, open or closed HMI or I/O from different manufacturers will complicate integration and the ability to use the best features of each control component.
For an open HMI system, development tools, such as Visual Basic, C++ or low-level programming tools and possibly development PC may be needed. For the closed HMI system, typically a higher-level configuration package is used to select objects and features that the system would need.
Clark Kromenaker / product manager—HMI, IPC, controllers, software / Omron / www.omron.com
