An HMI is more than just icing on a cake
Since it’s the way that users interact with a control system, don’t underestimate the importance of an effective HMI. It makes a huge difference to users now and down the road.
There are multiple HMI (human machine interface) platforms to choose from, with different styles and preferences driven by many kinds of variables. Driving variables can include integrator preference, customer preference, industry preference, technical support/availability, integrator support/availability, off the shelf software versus custom software, budget, and what best fits. Regardless the platform and driving factors, an HMI makes a control system complete.
An HMI application might originate at a computer in Anytown, USA, with an integrator at the helm that probably had too much coffee. But at the end, the HMI application will live, change, and grow with the end-user. The bottom line for an HMI application is for it to function alongside the control system and do what it was meant to do: give the end-user an interface that can interact with the control system. When developing an HMI application, it will ultimately consist of navigation, header, footer, alarm screens, graphics that match up the process, operator controls, and hand-off-auto capabilities on devices. If that basic functionality is met, then theoretically the job is done and done successfully. But is that enough? Raising the bar is key in HMI development. The HMI is what is seen and interacted with on a daily basis. Keep in mind the end user’s operators might interact with the HMI eight hours a day, for 40 hours a week, for years to come!
Finding ways to raise the bar on an HMI application is fairly simple. It can be as basic as making the application consistent. If there are multiple developers or if you’re adding to an existing HMI, consistency and cohesiveness goes a long way. Operators will find it comfortable to navigate and work across the HMI with little to no training.
Operators appreciate it when you match up to the P&ID and organize the graphics so they are easy to follow and understandable without being too complicated. Avoid bends and turns whenever possible since it helps following process flow. Consider how you arrange devices, pipes, etc., on the screens. If you have a graphic with three tanks with identical devices, make them exactly the same (with the exception of the devices) and if you have multiple graphics with similar or exact tanks, make them also appear the same. There is no reason to have one tank look slightly different from the one next to it and so forth. This is typically a rookie mistake and easily noticeable by the seasoned customer and other integrators.
Keep in mind the end-user’s people will spend a lot of time looking at those graphics. Over time, they will notice every offset and misalignment down to the individual pixel. Veteran operators will catch those glitches at first glance.
An organized header and footer for easy information overview and navigation will definitely enhance an HMI. Most customers have standards and preferences on how an HMI should look and function. If developing a new HMI application, use those best practices and raise the bar. If guidelines have been set for HMI development, make sure to follow them, but suggest enhancements where they make sense. When you do that, keep in mind that companies typically establish standards based on experiences built around hours of trial and error, however at times its just simply preference. Standards will vary from customer to customer. Some prefer loads of animation, while others discourage it. Most importantly, standards keep their HMIs consistent through facilities and across organizations with multiple facilities. Cookie cutter items are important, and if a standard is created and followed correctly, developing should take less time and meet customer satisfaction.
Several years ago I was doing some work for a customer alongside another integrator. At some point during cutover the customer asked the technician from the other integrator if he did any HMI programming. The integrator chuckled and suggested that HMI developing is like cake decorating and he was not interested in doing that. The statement has stuck with me since for two reasons. First, I was doing the HMI development on that project and he made it seem as if my role was inferior to his. The second part is that he compared HMI development to cake decorating! If you compare a control system to a cake, let’s say an ice cream cake, some of the ingredients can be the design, hardware, and control programming. If all done properly, the cake will taste delicious and a customer will keep coming back for more. On the other hand, if done poorly, the customer will take his or her business elsewhere and tell others to do the same.
There are many different cakes out there for different events much like different control systems for various industries. When choosing a cake, we look for one that has our desired size and flavor. We evaluate availability, price, and attractiveness. That last bit of decorating can tip the scale in favor of one bakery or the other, all other things being equal. It’s the same when choosing an integrator. Once we determine the basic functionality, the final decoration—the HMI—may determine the choice of vendor. A control system without icing can work and may even taste good, but where is the fun in that?
Bear in mind that this discussion is not intended to minimize the importance of other components of a control system, but to simply shed light on one. HMI programming should not be taken lightly or belittled since it helps complete a control system. Keep in mind that after many hours spent on PLC programming, HMI developing, building schematics, conducting I/O checkout, troubleshooting a VFD, wiring, troubleshooting wiring, reading manuals, startup/cutover, testing, site coverage, and everything else, at the end of the project when the control panels are closed up, and the integrators leave, the HMI is left to be the face of the control system and provide the means of interacting with the operators.
This post was written by Miguel Gutierrez. Miguel is the Senior Control System Specialist at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.
Case Study Database
Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.
Annual Salary Survey
In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.
Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.