As an end user and system integrator, Pete Diffley long endured the downtime headaches that come with managing a fleet of plant-floor, human-machine interfaces (HMIs)—and keeping the operators who use them up to speed as well. He points to how HMIs have traditionally been architected and deployed as a primary source of past frustrations, and now, as senior manager of global partnerships for Trihedral Engineering, developer of VTScada HMI and SCADA software, he proposes an alternate path forward.
Control recently caught up with Diffley to discuss where traditional approaches to HMI have fallen short, and how a different way of thinking can substantially improve system resilience and alleviate production downtime.
Q: It seems common sense to say that downtime is bad. Yet downtime due to issues with HMIs seems to be tolerated in some manufacturing settings. Can you explain why that is?
A: For decades now, the high-speed, high-volume production lines typical of the food and beverage, pharmaceuticals and other consumer-packaged-goods industries have relied on programmable logic controllers (PLCs) paired with HMIs to provide deterministic automation on the one hand and plant-floor operator visibility and interaction on the other.
The PLCs are purpose-built for industry, and designed for years of relatively uninterrupted operation. But the HMIs, often based on relatively short-lived information technologies, typically are less robust. There’s a cultural acceptance—a tolerance, really—that HMI workstations fail, but every time they do, the “money machine” stops and there’s a mad scramble to get things running again. Such failures paired with the need to patch, update and swap out obsolete hardware, software and operating systems accrue to a downtime tax that includes scheduled and unscheduled components.
Additionally, at the machine level you may have another layer of operator interface. Operator interface terminals (OITs) have their own local displays for machine configuration and operation. Further complicating things, there may be yet a third layer of production dashboards on the wall displaying aggregate KPIs such as overall equipment effectiveness (OEE)—a whole hierarchical universe of operational display systems, each created and maintained separately. When anything needs to be changed at an application level, you may need to take the line down. It all adds up.
Q: Some sort of redundancy would certainly help address this issue. But at the same time, having a hot standby workstation paired with every HMI seems a cumbersome and impractical solution.
Are there lessons that the discrete and hybrid industries can learn from how the continuous process industries, such as power or chemicals, implement redundancy?
A: The solution lies in how the HMI software itself is designed.
An online configuration methodology that allows changes to be made to the application without requiring a restart or stoppage of the production process is always the goal. It’s surprising that not all platforms support some form of this.
Consider a distributed control system that has multiple operator consoles networked to the same process controllers, rather than focusing on redundant pairs of primary and backup HMIs. This allows supervision to be transferred from one console to another while the other is updated. Also, each workstation can be a hot backup to every other workstation or to central plant SCADA server(s).
As a result, any of those nodes can take charge in the case of an outage, or if a change needs to be made on the local HMI instance. Further, the node enlisted to take temporary control can be just about anywhere—elsewhere on the production floor, in an on-prem data center or in the cloud.
And if the HMI software is designed to allow remote access via HTML 5, the operator can continue to run the machine from a tablet or smartphone, even as the local HMI is repaired, replaced or updated.
So, with this approach to redundancy, no one line is dependent on any one HMI.
Q: Can this same approach be used to manage those multiple layers of HMIs used for local interface, machine coordination and higher level KPIs?
A: Yes, and that very question strikes at another important aspect of how HMI/SCADA software should be designed—to allow essentially unlimited scalability from the perspectives of functionality and scope. For example, the core functionality of Trihedral’s VTScada software is essentially the same whether you’re implementing a simple, standalone 50-tag HMI solution, or one that spans multiple production lines, multiple locations and millions of tags.
A small, standalone system can be grown into a large, networked one without having to replace the software itself—the functionality is all there from the start. This also means that the same software used to gather data from and interact with a standalone machine can also help operators visualize the machine coordination tasks and production KPIs mentioned earlier. The software may run on different physical platforms at each level, with different functionality “turned on” at each, but all the HMIs operate together across a networked environment in a seamless and fully scalable fashion. A second advantage of basing all of these various HMIs on a software package like VTScada is that now all the displays are updated in real time; you’re no longer looking at an OEE metric that could be an hour old.
Q: I’d also offer that the ability to deploy and test proposed changes to an HMI—for example, on an updated operating system with a different look and feel—offers a significant opportunity to better prepare operators for how to interact with that new interface.
A: Absolutely. Many organizations use training systems that stand alone from the production units. These training environments represent an enormous investment of time and money spent in a vain attempt to keep them current and up-to-date with those on the plant floor.
You can show the operators what the new screens might look like—but what if you could show it to them with live production data from their production line, rather than with “simulated” data that may or may not resemble the machines they’re responsible for? In short, when an operator or technician has less than a full understanding of how to interact with their new screens, it creates downtime. This approach helps solve that training problem—and with a lot less effort and expense.
Q: A common mindset among those responsible for the care and feeding of traditional HMIs is that once they’re operating reliably, don’t upset the apple cart by making any changes. Meanwhile, the underlying hardware is aging, the operating system isn’t kept up to date, and security patches are neglected—all of which increase the risk of serious downtime.
A distributed HMI/SCADA architecture certainly make change easier. What other aspects of the Trihedral approach make it easier for HMI users to stay continuously current?
A: One of our core value propositions is that any project developed for the VTScada platform will remain forward-compatible for life. That means you can replace your current HMI platform with Microsoft’s latest Windows 10 OS, spin up our latest version of VTScada—and the HMI project you developed three or more versions ago will migrate easily to the newest. Moving project code to a new and unknown platform is at best a scary proposition. But our promise is that our software will always run your project on the latest and greatest platform. Always.
