Get even more answers from the instructors of the Aug. 13 RCEP Control Engineering webcast, “How to integrate new HMI or SCADA with existing automation,” archived for a year.
HMI, SCADA integration insights
- Get a more answers from the Control Engineering webcast, “How to integrate new HMI or SCADA with existing automation,” from two control system integration experts.
- Jason Israelsen, PE, is a project group lead at APCO Inc. Isaac Novosad is automation engineer at Huffman Engineering Inc.
- Article contains answers to audience questions that didn’t fit into the 1-hour of RCEP webcast instruction time.
System integration experts provide more about “How to integrate new HMI or SCADA with existing automation,” also the name of the Aug. 13 RCEP/PDH Control Engineering webcast. Below the two instructors for the course answered more audience questions than webcast time allowed.
Expert instructors (Figure) for the HMI/SCADA integration course (and advice below) are:
- Jason Israelsen, PE, is a project group lead at APCO with more than a decade of experience improving system efficiencies in the water and wastewater industries. His specialties include SCADA, HMI, and PLC programming, control panel CAD design, and control system commissioning. He holds BS and MS degrees in Mechanical Engineering from the University of Utah and is a licensed PE in Control Systems.
- Isaac Novosad, automation engineer, is known for his ability to grasp complex issues quickly and simplify them for efficient controls implementation. As part of the Huffman Engineering Inc. team, he is a resource for the utilities and the industrial-focused group, especially skilled at HMI and SCADA design. Past project work includes Phase III Chemical Building Improvements involving SCADA programming and system platform development as a member of a global pharmaceutical team. He is working with a large municipality and a 12-phased system shutdown to convert HMI and SCADA systems.
What criteria do you recommend for migration of HM/SCADA: replicating signal grouping and recreating HMI screens operators are familiar with, or completely transitioning to a new platform?
Novosad: So least some interested parties will usually want the new screens to closely resemble the old ones, so negotiate what you can, but stick with modern HMI best practices as much as politically possible.
Israelsen: I’ve seen this go both ways. Sometimes you recreate the screens and replicate the existing grouping, and sometimes you transition to something totally new. What should stay consistent, though, is the value of approaching the system with a fresh set of eyes. When you do that, you’ll usually spot the things worth keeping, the things you can remove and the places where you might need a change in direction. That’s where a standard like ISA-101 Human-machine interfaces really helps. It gives you a baseline to start from and solid concepts for high-performance, situationally aware screens. A lot of times I’ll have a feel for what’s right, and the standard gives me the reasoning behind it. Take a fresh look and be honest about what’s actually important. Not everything can be the same level of importance, because if it all is, then none of it really is.
What is the most overlooked piece of technical debt in legacy HMI/SCADA systems that usually isn’t discovered until halfway through an integration project?
Novosad: One thing we often find is that on an old HMI there are graphics or screens for pieces of equipment that no longer work or even exist. Other things that come up are low availability of equipment and knowledgeable personnel for testing, and political issues with getting continual buy-in for more radical changes to the HMI.
Israelsen: I see this as two questions: what’s the most overlooked piece of technical debt, and what’s the piece that tends to surprise you halfway through.
The most overlooked is the tag architecture, or the data architecture depending on your terminology. There’s a lot buried in there: scanning, naming, descriptions, scaling, alarming and the data types themselves, whether a point is an integer, a float or a double. Then there are deadbands and historical deadbands, how points are grouped, whether they live in structures, which alarms are meant to be grouped together, and on and on. There are so many details that it’s easy to take the whole layer for granted, and that’s usually where I find the most obsolete material too. These are artifacts that have been carried along for years.
The piece that surprises you halfway through tends to be the specialized scripts, calculations or control logic. It catches people off guard because it’s rarely at the forefront. It ends up being more of an afterthought buried down in the HMI/SCADA system, and you don’t find it until you’re already in the middle of the work.
What are the key components in HMI interface and the challenges associated with it?
Israelsen: I look at this from the developer’s and operation’s perspectives.
From the developer’s side, the key components are templating, trending, alarming, and navigation, and just about everything else supports those. Templating is about being able to develop, maintain and push changes out efficiently. Trending is about conveying data in a scalable, reliable way. Alarming carries the most detail behind it: whether it’s convenient, whether it’s integrated into the same system, and whether it’s easy to template and keep consistent and reliable. Navigation is where the developer is trying to bridge the gap of handing information along to operations.
From operations, the components are similar, but the reasons change. Templating matters because it keeps things familiar, so operators aren’t working across a bunch of disparate screens. For alarming, the questions become whether an alarm is obvious, whether it’s maintainable, and whether the notifications are reliable. For trending, it’s whether it’s accessible and easy to use. Then navigation is about quality of life for getting to and viewing the information.
As for the challenges, templating exists for scaling, so getting the templates right so you can reuse and leverage that data is harder than it sounds. Trending, if it isn’t efficient and reliable, can bog a system down, and you’ll see it the moment you put a whole bunch of trends on one screen. Alarming comes back to the same themes. There are a number of ways navigation can be architected, and operations generally has a certain method they need/want. Getting on the same page takes time and effort.
What’s the best variables naming strategy?
Israelsen: The best variable naming strategy is the one you’ll stick with and back up with a procedure or standard. I’ve seen a lot of different naming structures over the years, and they all have their own pros and cons. But the single worst option is to follow no strategy at all. Whichever one you land on, be intentional about the choice, and then the real work is following it and keeping up with it over time.
To what extent will the simulation be accepted by a client? is there a template of minimum requirement for acceptance?
Israelsen: This is a tough one, because in my experience it varies drastically, client to client, group to group, and sometimes even person to person inside the same client. The best approach I’ve found is to get everyone on the same page early and define what meets the requirements for acceptance. I’ve seen both ends of the spectrum. Sometimes the simulation ends up being more than anyone needed, and people wonder why we spent the time. Other times people wanted more testing and asked why more effort wasn’t put in. Both come down to the same fix, which is communication and defining the scope up front.
If I had to name one general practice, it’s this: define your acceptance criteria in writing before you build the simulation and tie each one to something you can demonstrate: These signals map, these interlocks trip, this sequence runs, this alarm fires. The point of the simulation is to prove what you agreed to prove. Doing that up front is what keeps the “this was too much” or “this wasn’t enough” conversation from showing up at the end.
How will SCADA solutions meet the operational technology zero trust architecture requirements released on Nov. 18, 2025?
Novosad: One of the initial important aspects is gate all control functionality behind security logins. Group each type of control into security groups and give out permissions to personnel on a need-to-use basis, and make sure each user has a unique log on, preferably tied to an existing identity management system. Next, segment devices on the OT network and implement constant monitoring of the OT network.
Mark T. Hoske is editor-in-chief, Control Engineering, Arrowfly, and moderator of this webcast, [email protected].
Keywords
More answers on HMI integration, SCADA integration, HMI upgrades
Consider this
Need a PDH? Get information about HMI and SCADA integration.
You also might like
https://www.controleng.com/sneak-peek-how-to-integrate-new-hmi-or-scada-with-existing-automation/
Also read from Control Engineering
Roundtable: SCADA’s role in industrial control
https://www.controleng.com/roundtable-scadas-role-in-industrial-control/
