What is a High Performance HMI? Learn about the intricacies of this approach to the control room HMI from Jeremy Coleman of Northwest Natural, including how the High Performance HMI delivers enhanced visual information to the control room enabling operators to more rapidly understand the operating condition.
You will also learn about the history of the High Performance HMI and the latest technological developments, including how to the High Performance HMI manages the high volume of data available from SCADA.
High Performance HMI Show Notes, Links, and Insider Terms:
- Jeremy Coleman is the Gas Control Manager at Northwest Natural in Oregon. Find and Connect with Jeremy on LinkedIn.
- HMI is Human Machine Interface. It is the user interface that connects an operator to the controller in pipeline operations. High performance HMI is the next level of taking available data and presenting it as information that is helpful to the controller to understand present and future activity in the pipeline.
- Strip chart recorders are physical devices that use a roll of paper to record data over a timed period. Strip charts use pens to plot the data as the paper passes through each interval.
- PAS (Plant Automation Systems) provides software solutions for process safety, cybersecurity, and asset reliability covering the energy, process, and power industries.
- An alarm management program is a method to manage the alarm rationalization process in a pipeline control room.
- Agile development refers to a set of values or principles that software developers rely on when collaborating with cross-functional teams. The goal is rapid and flexible response to change as software continues to improve and expand.
Full High Performance HMI Episode Transcript
Russel Treat: Welcome to the “Pipeliners Podcast,” episode five.
[background music]
Announcer: The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations.
Now your host, Russel Treat.
Russel: Thanks for listening to the Pipeliners Podcast. We appreciate you taking the time to listen to this episode. To show our appreciation, we will let you know about our signature price pack. We are offering a free, customized YETI tumbler to one listener every episode. How do you register to win? Simply visit pipelinepodcastnetwork.com/win, that’s pipelinepodcastnetwork.com slash W-I-N to enter yourself in the draw in. This is our way of saying thank you for being part of the show.
We’re really lucky to have with us today Jeremy Coleman. Jeremy is Gas Control Manager at Northwest Natural, a gas utility up in the Oregon area. I’ve had the privilege to work with Jeremy on a project back in 2012 when we did alarm management, when we were early on in the rolling out of the control room management role.
In doing that, Jeremy and I got to know one another. He’s one of those guys, he’s a real innovator. He’s forward thinking and I think he’ll add a lot. We’re going to get to talk about Jeremy about high performance HMI and what he’s been doing in his control room.
Jeremy, welcome to the Pipeliners Podcast.
Jeremy Coleman: Thanks, Russel. Thanks for having me.
Russel: How’d you get interested or how’d you first hear about this idea that’s called high performance HMI?
Jeremy: This was back in 2011. I went to a conference up here in the Pacific Northwest. There was a track and then in that track, it was the gas control track. There wasn’t a lot going on in there, but there was this thing that caught my eye and it was called high performance HMI.
I know what high performance means. I know what HMIs are, but I had never put those two things together. I had no idea what it meant. I went in and I sat there for an hour and the concepts that were brought out just blew my mind.
Russel: It’s an interesting comment. For the listeners that might not know, some of the buzzwords or jargon, HMI is Human Machine Interface. It’s a pretty common term. It refers to the pretty computer cartoons that the people in the control room watch. How is high performance HMI different than just what we typically think of as HMI?
Jeremy: What it was for me was it was changing my mindset related to HMIs. I came up in the operations area. When I got in the control room and the role of a controller, you only know what you know.
The HMIs that were put in front of me were just, that’s what they were. I didn’t have the understanding of what they could look like, what they should like, the functionality that they should provide. They just were what they were.
When I was first introduced to high performance HMI, it really opened up that first door in my mind that said, “Hey, there’s something else out here. There is a better way to visualize the data that’s coming into your room and really will help inform the information that you’re trying to get to.”
Russel: Yeah. I think what you just said, it’s the deep concept because you talked about two things. To my mind, they’re distinct. One is the idea of data, the physical numbers coming up to the control room.
The second is the idea of information, which has taken that data, putting it together in a way that is helpful to the controller in terms of understanding where they are with the pipeline and understanding where they’re headed with the pipeline.
Is that a fair commentary thing?
Jeremy: It really is. It really is fair. I can give you an example of how they really broke it open to me. One company really has used this example a lot, but I’ve heard others use it. I’m just going to verbally plagiarize this thing right here. I don’t think anybody’s going to care.
This was an industry event and they started off by saying, “How many people in here are veterinarians?” Of course, nobody raises their hand. They say, “We’re going to show an example. Your cat’s sick. You take it in, and get some blood work done, and they threw a bunch of data up on those screen.”
Said, “Is your cat sick?” Nobody knows. They say, “Let’s massage this data and apply some high performance HMI principles to it.” Through the use of some manual analog indicators and some other objects, they put the same data up there and then they ask the questions again, “Is your cat sick?”
Within seconds, everybody in the room said, “No, the cat is not sick.” He said, “Well, none of you are veterinarians. How do you know that?” By using objects, by showing acceptable ranges, in our case, it would be operating ranges, and then showing where your values are at, just in seconds, your mind can see this and makes sense of it.
That really was what got me started in this.
Russel: You just did a mouthful there. I hadn’t heard that example before. That’s interesting. It reminds me of the old Star Trek episodes where you had the tricorder and the person laying on the table and all the symbology up above him. When all the indicators went to the bottom, you knew the person was dead.
Jeremy: That’s an excellent early example of a high performance HMI. None of us are medical professionals. Certainly, not in the future on a starship. When they put those up there, like you said, when you see them drop to the bottom, you just know that that guy in the red shirt’s not going to make it.
That’s exactly what we’re talking about. Picture taking that, and applying it to a pipeline, and to all the data that we get on that. The possibilities are endless.
Russel: Maybe this is overly simplistic, but it’s pretty easy to think about blood pressure, and heartbeat, and oxygen level of the blood as indicators of are you alive or not, maybe breathing. What would be the analogous things you’re going to look at on a pipeline? In particularly, a gas utility where you work?
Jeremy: Obviously, pressure and flow are two biggest ones and they’re the easiest ones to pick. For example, here in the Pacific Northwest, we get warm this summer, we get cold in the winter. We have our operating ranges that we like. You can call that the range between a high and a low alarm.
We also know that in the winter time, some of our pressures will be dipping down into what would be the low alarm or alert and that’s okay. We know that when it’s cold, we’re going to dip down in there. The flip side of that is in the summertime, when demand is down, pressures are going to be up and we might get up into the high range a little bit, and that’s okay.
If you just rely on an alarm, an alarm is just going to tell you if you’re in the high state, if you’re in the low state, whereas if you have an indicator up there that shows you the full range, that shows you your proper operating range.
Yeah, you might be a little bit on the low side, but if it’s a morning like today, the middle of November, towards the end of November, I expect to see that just down inside of that, inside of the low operating range.
I know just for my system and from my experience that that’s okay versus walking in in the middle of summer and glancing up and seeing that indicator in the low range, I instantly know that something is not right and I’m going to start to dive into that issue.
Russel: That’s interesting because you’re actually combining your knowledge of the system and your knowledge of, in this case, the time of year and the weather, and correlating that to what your high performance HMI is telling you.
The way things look in a mid-November timeframe versus the way things look in the mid-August, your expectation is that they would be different.
Jeremy: Correct. Really, a well-designed HMI should be such that you can just take anybody off the street, put them in front of it, and they should be able to identify if something doesn’t look right. Doesn’t mean they know what it is, but they should be able to just look and in an instance, say, “That one looks like it’s something’s bad happening.”
Through training and then through experience, that’s where you dive into that and you know how to figure out exactly what your issue is.
Russel: That sounds relatively straightforward when you just talk about it, but was it difficult to figure that out for your system? Was that a challenge?
Jeremy: It’s a big challenge. For starters, getting others to buy in on this concept is really the first step. I was a very early adopter and boy, I drink the Kool-Aid. I was running around trying to get everybody excited about it. It’s really hard. You’ve got to find somebody with an open mind.
The second part is we were lucky enough to have somebody come in and help us achieve this vision. That was through figuring out our processes, figuring out how we view our system, how we operate our system, and then breaking those down into appropriate HMIs. That’s a lot of work. That’s really only the beginning of the work.
Once you identify the types of data that you want, then you just start to get into this, “Okay. How do we want to visualize this?” That’s where the folks that came in helped us out quite a bit. Even then, that’s very iterative process and it takes a lot of back and forth. Just like any good project, what’s in your mind isn’t often what comes out the first time.
It takes a while to get there, but once you do and you start using the screens, you really become a lot more intelligent about how you want them.
I guess that’s the thing I’d really want to impress in front of everybody the most, is that don’t expect to hit it out of the ballpark on your first generation of screens or HMIs. Not even your second or your third. Know that what you are creating is going to be thrown in junk pile quite quickly and you’re going to move forward. That’s just the way this process goes.
Russel: When you make that comment thing, I think about in the people we work with is… in the pipeline world in particular, we tend to think more like engineers and guys that do construction. The idea of doing something, to learn, and throw it away, and do something else, that’s out of the box.
Jeremy: It really is, but with a little bit more of an IT perspective on it, because this is a… it’s funny it’s an operations driven product, but it is a technology solution, and because it’s new, because there’s so many moving parts, you have to go into it knowing that you’re just going to use it for a short time. You’re going to get smarter and you going to move on. That’s hard, you’re right. Especially in this industry, that’s really hard to do.
Russel: This is one thing I say, it’s like being an offensive lineman, that the only time you get your number called on the public address is when you mess up.
Jeremy: Right.
Russel: Innovation in critical infrastructure where there’s high risk is challenging. Do you actually did your high performance HMI as a separate project, a separate set of actual physical displays in the control room, separate and apart from what the controllers are using on the console to actually operate the pipeline?
Jeremy: Correct.
Russel: That’s actually creative, because it gives you the freedom to experiment and change, or changing that in their core console is a different problem.
Jeremy: One of the things I’ve learned being in the control room for all these years is that if it’s not working, the controllers won’t use it. It doesn’t matter if it’s a HMI or a new chair. [laughs] If it’s not working, it’s going to get rolled over in the corner and it won’t be used.
One of the things I like to do, especially when introducing a new concept like this, is to build it as a standalone, put it out there, train all the controllers on it, do my best to explain to them why I think it’s a good thing, but then I sit back and I watch, and I like to see how much use it gets.
In our case, one of the first screens we rolled out was a level one, which is just a system overview of our whole system. It’s that you walk in the room and that’s the first thing you look at to get a real quick idea of where things are at. I just wanted to see how often it would be up in display.
A couple of the controllers were early adopters and it was up. A couple of them were a little bit slower, but it didn’t take that long. I noticed that it was up pretty much all the time. I took that as my queue to go ahead and start moving forward.
Russel: That’s creative. I would have never thought about approaching it that way, but that’s interesting. I guess the idea that you’re saying is, if I do something and people use it, then explore that, develop it. If I do something and they don’t use it, throw it away, and try something different.
Jeremy: Yeah. In our case, this was a hard-learned reality for me over the years. We’d have screens that weren’t driven by us. They would be driven by others just the way we used to operate this. Somebody would have an idea, and they would make a screen, and they’d be excited.
It’s like having your own baby, and you’d bring it in, and be excited, and they’d roll it out. I’d watch as the controllers smile, and it would never see the [laughs] light of day again. You hurt some feelings that way sometimes, but I learned over time that, if it’s going to be good, they’re going to use it.
Russel: I’m one of these guys that like the history of technology. If you understand how the HMI evolved, we used to do all this with mechanical and pneumatic devices, physical strip chart recorders with paper, and pens, and all that type of stuff. We replaced all that with computers, because we could change it, it was less expensive.
The computers, when we first put them in, were pretty limited and all those computer systems were built by engineers. They weren’t built by information systems guys and they certainly weren’t built by people who were creative in terms of understanding how to build displays in a way that people would interact with it.
We still to a large degree have that as a legacy in our industry, where it’s engineers that are building these screens, not operators. Certainly, not people who are highly trained in the art of presentation or user interface.
Jeremy: Yeah, you’re right on. We’re way behind in that. Even at my own company where I’ve been working on this for quite a few years, you can just hear it in the language, “Gas Control wants the screen change, what do you think?”
That actually should never, or even be a question amongst other workgroups. If it’s a screen that Gas Control uses and they need it, then we should change it. When I talk to my peers in the industry, a lot of them are going through the same thing. We’re experiencing some growing pains. People are starting to figure this out a little bit. High performance HMI is a buzz word right now.
But, I have been hearing people use it more even if they’re not a 100 percent sure of what it means. I am hearing it enter into conversation and that’s a great thing. I really like to push this to the point where we don’t call it high performance HMIs, they just are HMIs, and they are very high performing.
Russel: I actually have a little bit different premise than that. We shouldn’t call it high performance HMI or HMI. We should call it the high plan operation system.
Jeremy: Yeah, absolutely.
Russel: It’s another point. There’s this belief… I don’t know if anybody actually states this. There’s this belief that whatever we build for Gas Control is going to work for everybody else, and that’s just not true. The reality is, we all need the same data but we all need to manipulate it, present it, analyzed in a different way, because we’re using it for different purposes.
Jeremy: You’re absolutely right.
Russel: The user interface I interact with needs to be correlated to the job I’m trying to do. We haven’t thought about it that way.
Jeremy: No, we haven’t. You’re absolutely right, it’s different. Even for me just as the Manager of Gas Control, I sit in Gas Control. My office is in Gas Control. I’m using the same data that my controllers are using, and yet I look at it completely different than they do.
They’re looking at it right in the here and now, for the next couple of hours, and then trending back a day or two just help inform their decision, whereas, I’m looking at things the same data in much larger blocks. Even within my own room, we’re looking at the data differently.
For other departments, you’re right. They need it as well, but they need it in far different aspects than we use it for.
Russel: Yeah. This conversation is interesting to me, because if you look at the more accounting or business system software development, those guys had been talking about data and user interfaces that way for years, back age. That way of thinking is brand new to the control room.
Jeremy: It is.
Russel: What do you think in the project you did? What do you think went well? What was the thing that surprised you that you didn’t anticipate?
Jeremy: That’s a difficult question only, because our project didn’t go as well [laughs] as I wanted it to. What went well is actually the adoption of the concepts by the controllers. They recognized pretty quickly the possibilities. It didn’t take long for the conversation to change from, “What is this new screen?” to, “How come our other screens don’t look this way?”
That was a positive moment for me. I knew that we were on to something. It also has opened up new things that we want to do in the control room that are all data related, that aren’t necessarily SCADA driven.
Russel: Help me understand that distinction between data related but not SCADA driven. What does that mean?
Jeremy: Sorry for opening that up. I don’t know how many hours you have to talk about that but over the years, and talking with other groups, there’s been a comment that’s been said several times and that comment has largely been around, well, the Gas Control has SCADA. What else do they need?
The answer to that is we need a whole lot more. The amount of data that goes in and out of a gas control room is really amazing and it’s not all SCADA related. There’s a lot of operational data that comes in, that could come in orally, somebody on the radio, somebody walking in. It could come in via written procedures.
It could come in via asset management. What settings have certain devices been left at? There’s a whole lot that goes in and out of a control room that simply is not captured in the right ways. That’s where I’m moving to now, is recognizing that the high performance HMIs that we’ve been talking about a little bit are great.
They’re a tool it is a must have. But if it is consisting of really just SCADA related data, there’s a lot more that we need besides that. We’re going to have to start figuring out a way to incorporate all that.
Russel: I think of that and weather data in particular for gas utility is critical. Knowing where the crews are, when their trucks, and that’s data, and it’s important to operations, but it’s not SCADA data. There’s many, many other examples like that, your scheduling, what commitments you’ve made to others. That type of thing.
That’s all important because those are key inputs to the operations process but not part of SCADA. What was the biggest challenge with this whole high performance HMI?
Jeremy: The biggest challenge was in being introduced to this concept and receiving some outside help and trying to realize the vision. The outside help stopped there. They weren’t technology experts. They were visual data experts.
Bringing that in and trying to install that into existing SCADA system that we had, we soon realized we had some severe technology limitations in our SCADA system, and there’s just certain things we couldn’t do. For instance, putting multi-plotted radar charts proved very challenging, but we were able to do it.
When my design called for six radar plots and other objects, it started taxing the system. We ended up having to stop our HMI process and upgrade our system just to help accommodate that. That’s been the biggest challenge from our standpoint.
Russel: Just chewing on that because what I hear you saying is, “We brought some guys in who were extremely creative in terms of understanding how to really add value in displays, and then we went to execute that, and those guys were consultants in terms of concept but not consultants in terms of implementation. Then we got stuck in the yeah, but that’s not going to work in this piece of technology.”
Jeremy: Correct. At that time, it wasn’t part of their business model to do that. It wasn’t anything that we contracted them for, just to get the concepts out and to help us get drawings and everything in our HMI philosophy style guide. All of that was fantastic and a very necessary step.
Just the way that it worked out, their help ended there and then I was left in a position where I didn’t have that internally available to me. That stalled us out for a little while.
Russel: The reason I bring this up is I think for people that might be listening to this and might be thinking about trying to do a high performance HMI themselves, I think this is a really important consideration. There are a multitude of skills necessary to do a really good system in Gas Control.
Design of high performance HMI and the people that are good at that is not the same as the guys who are good at building SCADA screens. It’s important to understand that whatever you come up with a design, there’s going to be a couple of challenges. One, did you get it right? Is that what people want and are they going to use?
The other thing that you’re pointing out and I think it’s important to understand is, are you actually going to be able to do it with the technology you currently have? That’s true with anything. Any of us that are being creative and trying to push the envelope, we will find the edge of the envelope, just cut of the nature.
Jeremy: Absolutely, and sometimes we’ll walk right off that edge, but that’s how we push it out a little bit further though.
Russel: Would you mind mentioning who it was that helped you guys out with coming up with your high performance HMI plan?
Jeremy: No. It was PAS. I believe it’s Plant Automation Systems.
Russel: We’ll put that in the show notes, and we will link that up so that the listeners, if they’re interested, they can find out more about that. If you were talking to one of your buddies and they were thinking about starting a project like this, what advice would you give?
Jeremy: I think the advice I’d give them is, one is you’d have to have an evangelist for it. I wouldn’t go into this with everybody thinking, “Yeah, it’s a good idea. We’ll try to knock part of it off.” You have to have somebody that recognizes the value, and that is in a position to continually push forward.
Once you have that and you get some agreement, get the right folks together, get your IT folks together, get your controllers together, get everybody on the same page and then enlist that outside help to come in and focus your efforts on design and creation of your documents.
You can spend a lot of time just on philosophy, and frankly, you really should do that because everybody’s doing the same thing but a little different. What’s important to one company is going to be of a little bit less importance to another.
Once you move past that, having the IT folks involved that are going to be the ones that are building this, as we discussed, is critical. Like we started off with, knowing that you’re not going to hit a home run on your first try. You’re going to have some ups and downs.
You’re going to roll a screen out that you’re excited about, but the controllers are going to go, “Well, this is nothing like you promised us.” [laughs] Recognize that you’re just going to have to keep moving forward and you’re going to tear down and rebuild. The good news is that you get a lot better at it really quick. You don’t have to tear a whole lot of them down after you get up and running.
Russel: I mean, really what you’re talking about, this high performance HMI is not something you’re going to create, and when you build it, you have it. It’s more of a capability you’re creating within the company.
Jeremy: It really is. It’s a lot like an effective alarm management program. If you go out and just rationalize all your alarms and walk away from it, good job for doing the first part, but you’re shooting yourself in the foot for not staying up on it. HMIs are the same thing.
They’re living, breathing, you’re going to create them, your business is going to — you know, importance always ebbs and flows, right? Someone’s way of operating is really important one day and then might phase out, so you’re going to make some changes to your HMIs. Maybe you’re adding a new station somewhere, a new rig site, a new pipeline. Maybe you’re taking some things away. Your HMI has to be able to be flexible enough to accept those changes and timely as well. You don’t want bad information staying up there.
Russel: That’s really critical. I sure appreciate you taking the time to do this. I’m certain that those that listen to this are going to find some real value in it.
Jeremy: I hope so.
Russel: Would you be willing to come back and talk to us about some other topics down the road?
Jeremy: Yeah, I certainly would be. I love this. I think it’s fantastic.
Russel: We certainly appreciate you joining us, Jeremy. When I listen to these things, one of the things I’m trying to do is I’m trying to boil it down to three takeaways, like this old house where the guy says, “This is what I learned about putting in a water heater.”
Here’s what I think I learned. I’d like to get your commentary on this. The first is, you’re going to need to iterate, you’re not going to get it right the first time. It’s going to take some staying with it to get smart.
Jeremy: Correct.
Russel: The second is, the controllers will tell you whether it’s working by whether or not they use it and it’s important to have them involved and have them buying in.
Lastly, you need an evangelist, and the evangelist is going to have to build a team.
Jeremy: Absolutely. You know that first part when you were repeating that back, it dawned on me that technology folks, they love to call that the agile approach. If you hit them with those words right off the bat, that will set the landscape for them.
Russel: That’s one of the IT buzzwords de jour: agile development.
Jeremy: You get hit in the head with it enough, you start to learn a little bit, and that’s what’s happened to me.
Russel: Jeremy, if somebody wanted to get a hold of you or reach out to you and ask questions about this whole high performance HMI subject, how might they do that?
Jeremy: I think probably the best way would be to send me an email and then we can work out the logistics from there. My email is jeremy.coleman@nwnatural.com.
Russel: Well, Jeremy, thank you very much. It’s been a pleasure, and I look forward to doing it again.
Jeremy: Thanks, Russel. I appreciate it very much.
Russel: Just a reminder before you go, that you should register to win our customized Pipeliners Podcast yeti tumbler. Simply visit pipelinepodcastnetwork.com/win. That’s pipelinepodcastnetwork.com slash W-I-N to enter yourself in the drawing.
[background music]
Announcer: Share your questions and comments with us at pipelinepodcastnetwork.com. You can support the show by liking and following us on SoundCloud or by rating and reviewing the show on iTunes, Google Play, or Stitcher. Thanks for listening to the Pipeliners Podcast.
Transcription by CastingWords