This week’s Pipeliners Podcast episode features Russel Treat and Philip Jones of EnerSys Corporation discussing the fundamentals of High-Performance HMI for the pipeline control room.
In this episode, you will learn about the difference between HMI and High-Performance HMI, the importance of keeping things simple in an HMI build, why the perspective of a controller is invaluable for building HMI displays in the control room, and how to ensure the HMI is built to support multiple purposes at the controller level, manager level, and operational level.
You will also learn about the upcoming changes to the API 1165 RP for HMI displays and how controller preferences have changed over time. Listen for unique HMI insight to apply to your role in pipeline operations!
High-Performance HMI: Show Notes, Links, and Insider Terms
- Philip Jones is the lead SCADA developer, builder, and engineer for EnerSys. Connect with Philip on LinkedIn.
- SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote location. SCADA breaks down into two key functions: supervisory control and data acquisition. Included is managing the field, communication, and control room technology components that send and receive valuable data, allowing users to respond to the data.
- HMI (Human Machine Interface) 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 the present and future activity in the pipeline.
- The HMI Style Guide provides details in the universal language of users such as colors, lines, text, objects, navigation, and system features in compliance with a philosophy document. This approach attempts to harmonize all programmable systems and a common HMI.
- API 1165 is the Recommended Practice for Pipeline SCADA Displays. This standard outlines the best practices for designing and implementing displays that are used by pipeline controllers to evaluate information available in all operating conditions.
- Alarm Management is the process of managing the alarming system in a pipeline operation by documenting the alarm rationalization process, assisting controller alarm response, and generating alarm reports that comply with the CRM Rule for control room management.
- Alarm Rationalization is a component of the Alarm Management process of analyzing configured alarms to determine causes and consequences so that alarm priorities can be determined. Additionally, this information is documented and made available to the controller to improve responses to uncommon alarm conditions.
- Watch the video of a Cessna 172 pilot taking off, flying, and landing a private plane with no prior real-life flight experience, based only on his experience with a desktop flight simulator.
High-Performance HMI: Full Episode Transcript
Russel Treat: Welcome to the Pipeliners Podcast, episode 87, sponsored by Gas Certification Institute, providing training and standard operating procedures for custody transfer measurement professionals. Find out more about GCI at gascertification.com.
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. I appreciate you taking the time, and to show that appreciation, we are giving away a customized YETI tumbler to one listener each episode. This week, our winner is Joe Atkinson, with Boardwalk Pipeline. Congratulations, Joe, your YETI is on its way.
To learn how you can win this signature prize pack, stick around until the end of the episode.
This week on the Pipeliners Podcast, we have a new guest, Philip Jones. Philip is the lead SCADA developer for EnerSys Corporation, and he’s coming on board to talk to us about the high-performance HMI and API 1165. Philip, welcome to the Pipeliners Podcast.
Philip Jones: Thanks for having me.
Russel: Are you sure? Because I’ve been trying to get you to do this for a long time, and I think you’ve been a bit reluctant.
Philip: [laughs] I have been a little reluctant, but you finally roped me in, so here I am.
Russel: [laughs] Maybe roped in is the right way to say that.
Russel: That’s actually a good tee-off for the next question. Tell the listeners about your background and how you got into building SCADA systems.
Philip: Sure. I’ve been working with you for probably, if we go total, maybe 14 years now? Basically, I just started working on little things, and poking my nose in people’s projects, and just learned the ropes.
Russel: For the listeners’ benefit, how old were you when you first started working around EnerSys?
Russel: [laughs] That’s right, and you built an excellent set of stairs to our temporary offices.
Philip: Yes, I did.
Russel: From there to SCADA expert, I’d say that’s a pretty good career path.
Philip: It’s been a pretty good arc so far.
Russel: [laughs] That’s exactly right. Just to clarify for the listeners, we’re talking, having a little bit of fun here.
Philip is our lead SCADA engineer, designer, builder. He’s the owner of all things we do and what we call our Intelligent Operator Console. He builds high-performance HMIs for pipeline operators and supports our customers. That’s what Philip does, and that’s his background.
I asked him on because there’s a new version of API 1165, which is the standard for HMI for pipeline operations, HMI being human‑machine interface, and Philip has been supporting me on this process. I thought it would be really helpful to bring him on and ask him a bunch of questions, starting with, how long have you been building high-performance HMIs?
Philip: I think in total, it’s probably been about 9, maybe close to 10 years now.
Russel: Pretty much around the time that the control room management rule was beginning to come out, and this whole idea of, what is a high-performance HMI, and what is the future, and how to do HMI under the rule, and all that kind of stuff started. You’ve been learning along with the rest of us.
Philip: [laughs] Yeah, I think that’s the best way to put it.
Russel: What would you say you’ve learned in nine years or so of doing all this about what the high-performance HMI is?
Philip: In the simplest words, it, keeps it simple. A high-performance HMI is really a nice, clean interface. It should be real simple for anybody to walk up to and understand. Even if you don’t have any knowledge of what you’re looking at, you should be able to look at it and get a pretty good idea of what exactly you’re seeing, and how things are running.
Russel: How is that different than classic, the kind of stuff we were doing when you first started working with us on SCADA projects?
Philip: I’ve seen over the years a lot of really bad HMIs. [laughs] A lot of them come from just examples when learning about the high-performance HMI of what not to do. You look at them, and you can tell really quickly if you put side by side a bad HMI versus a high-performance HMI, it’s a cluttered mess, usually.
Russel: I think that’s extremely well said, Philip. You say, keep it simple, make it easy to understand, but it’s not easy to keep it simple. At least that’s been my experience.
Philip: No, it’s not. [laughs]
Russel: What do you think makes creating a high-performance HMI hard?
Philip: I think probably the biggest challenge is understanding what you’re trying to get across, the operating context. It’s really easy now. Data’s cheap these days, and you have access to a ton of information.
If we’re talking to somebody who wants an HMI built, they just say they want everything, and if you were to put everything on there, it turns out to be not very useful.
Russel: How do you go about organizing the information?
Philip: It’s a lot of conversation and just trying to understand the operating context that you’re trying to get across. I’m not really sure how you learn the trade, but I’ve been doing it long enough. You just get pretty good at putting together, “Okay, here’s what actually needs to be displayed. Here’s the details I need to see, and here’s the overview of things.”
Russel: You’re talking about operating context. What I’m trying to get you to unpack a little bit is, what do you mean by operating context, and how do you learn what it is? I think it would be very easy for me to say something like, “Well, the operating context is to make sure your deliveries don’t have a problem.”
Philip: Sure. As we’re talking here, I’m thinking of it more on a screen level, just screen by screen, through an HMI, “For this screen, here’s what the operator needs to do. Here’s what your controllers are looking at.”
You’ve got your basic graphic sets, and you try to keep things easy to understand. The pump always looks like a pump. Your valve always looks like a valve, and then you provide all the details for those things, typically in a faceplate or something like that.
Russel: That sounds simple and straightforward enough. Maybe I’ll talk about this a little bit. In our graphic approach, we have what we call Level One, Two, and Three graphics, where a Level One is a summary graphic, and a Level Three is a detail graphic.
Russel: Sometimes, you use a Level One graphic, and sometimes you use a Level Two graphic, a summary graphic, or a detailed graphic. Sometimes you use a summary graphic on a detailed screen, and sometimes you use a detailed graphic on a summary screen, which I’m thinking anybody listening to this is going, “Yeah, now you’re just talking in circles.”
Russel: Maybe you could illustrate some specific examples of when you use a detailed rich graphic versus when you might use a simple or summary graphic.
Philip: Sure. I think it is really situational, and it’s dependent on the screen that you’re working on. For example, if on your overview screen, you try to keep those really clean. The whole goal is to just be able to glance at it and know, like you said, “Am I making my deliveries? Is everything normal and safe?”
There may be a very particular pressure that you know goes out of whack or that you really need to keep an eye on. There, you may, on that overview, throw up a detailed graphic with the actual value, the actual indicator, a trend tail on it, and things like that.
It’s not always you try to think of them as level ones go with Level One screens, and the more detailed stuff goes on the detailed screens, but you do have to be a little flexible and move those around as needed.
Russel: I think that’s a really good example, Philip, because I can think of several situations where you have a whole lot of pressures, and if you put a very rich graphic with a trend tail that consumes a lot of real estate, it makes the screen busy, and that might not be important on a meter pressure. If I’ve got a critical pipeline pressure, probably is important.
Philip: That’s exactly right.
Russel: What kinds of things would be different based on operating context, and what kind of things would be the same?
Philip: You’re definitely going to want to keep your major equipment pieces and things like that standard throughout your system. You don’t want a valve looking like this here, and like something else somewhere else.
As far as differences, and even more to that, you want your control interfaces to be the same across everything, and the way you input values to be same. I’ve seen a lot of hodge‑podge HMIs where you had somebody who was working on it for a while, and somebody else came years later and worked on it their way, and so, screen to screen, it’s not consistent.
I think keeping things consistent across the board is always ideal, but there are places, especially analytical screens, where you need to put those details in there and so people, engineers or analysts, can get to the data they need, but those kind of screens really don’t help people operate. They just help diagnose things.
Russel: An operating screen might be, I’ve got a station, and I’ve got a screen where I used to move valves, or set a line up, or something like that. An analytical screen might be, here’s a meter, and all the details about the meter, and how it’s configured, and all its internal parameters, and all of that kind of stuff.
Philip: Sure. Exactly.
Russel: Which might be helpful if I don’t believe the meter number I’m seeing, but I don’t need all that to understand, am I hitting the volume I’m supposed to hit?
Philip: Right. In those kind of super detailed screens, if you’re looking at those every day, you probably need to reevaluate how you’re building your HMI. There should be better ways to see that stuff.
Russel: I very much agree with that. I asked you here recently to build a bunch of graphics to provide some illustration and examples for the work that I’m supporting, and you’re supporting me on, related to the revision of API 1165. I know that that was a challenging task. I think it was probably more challenging than you thought it was going to be when you took it on.
Philip: By far.
Russel: [laughs] By far. By how much?
Philip: A whole lot. When you said, “Throw together some examples,” I said, “Not a problem,” and I thought I’d be done in a few hours.
Russel: What ended up happening?
Philip: You start trying to put graphics. When you had asked me, I was like, “Well, I’ll grab some screenshots and line them up with these examples that they’re looking for.” It turned into, when you just throw something down, sure, somebody can look at it and know what it is.
Just looking at a graphic or an analogue indicator, you can look at it and you know what’s being conveyed there, but to really point out all the details that are going on in that graphic, it took a lot of labeling, a lot of text to explain around alarm limits and things like that.
Russel: I think, Philip, that that conversation illustrates what the high-performance HMI is all about.
On the surface, it seems very simple, but when you start unpacking all the things that happen, given alarm states, and alarm limits, and alert limits, and notes, and locking out, and inhibiting, and you start getting into all these different things that the operator needs to be able to do to conduct their business, and all of a sudden, that simple pressure graphic, now there is, “Okay, this thing could look about 25 different ways.”
Philip: Yeah. You asked for a handful of examples, and I think that document turned out to be 20‑some odd pages of explanation, and arrow pointing, and explaining what you talked about.
All the little details around, “Here’s one indicator, but here’s all the different ways it can be displayed, and here’s all the information you’re getting, just from this symbol,” and things like that, which, like you said, is exactly what the high-performance HMI is all about.
Russel: Right. If you were going to give advice to a SCADA person who’s building a high-performance HMI for the first time, what advice would you give them?
Philip: I think keep it simple is one of the best ways to state that, to sum it up. That’s the best advice I could give, but you’d have to unpack what exactly that means because you don’t want it too simple or you’re not going to get the data you need.
I think the whole goal of the high-performance HMI is to convey a lot of information without burdening somebody looking at it to try and analyze what they’re looking at. You don’t want to have to spend the time to evaluate every single thing you’re seeing and put it together so it means something to you.
You want to be able to glance at it and get the information you need from it real quick, especially some of these control rooms just have hundreds of screens and you got to get that information real fast and move on to the next thing.
Keeping it simple and still getting the information across is the best advice I can give. A lot of people will ask for a lot of things on their screens, and it takes a couple of years of learning to say no. [laughs] At some point, you’re doing them a favor by saying no to some things.
Russel: That’s actually where I wanted to go next in our conversation because I know you’ve spent a lot of time working with controllers and folks that are actually using the screens you’re building. I consistently hear very good things about the work you do, and I think that the point that telling somebody no, that can be a hard thing if you will.
Philip: It can be.
Russel: They need to understand why you’re telling them no, and that there’s another alternative, and, “I’m saying no because there’s a better way to do this, and here, let me show you the better way.” Generally, when they see it, they go, “Oh, okay. Yeah, that makes sense.”
Philip: [laughs] I promise when I’m talking to our customers, I don’t say it so bluntly, but…
Philip: …you do. You need to explain it. First, you need to understand why they’re making the request. I think that’s a big part of it.
You have to try and figure out what exactly they’re trying to get out of that, and then hopefully, you can think of a better way to get that information across without…You know when you see a bad HMI with tons of numbers, how overwhelming that must be to look at every day.
Russel: Yeah, and I think a lot of people think a high-performance HMI as grayscale, but you can do a poor HMI is grayscale, just as easily as you can do a poor HMI…
Philip: You sure can.
Russel: …in black background. The ideas in high performance go way beyond just grayscale.
Philip: It’s actually interesting because over the years, the controllers, their original complaint was always ‑‑ like you said, I came in right when the rule was coming out ‑‑ and controllers really wanted their color. That was the biggest pushback all the time. They wanted their colored screens, and I think I’m getting a lot less of that now, so people are coming around.
You sent me an interesting — I don’t know if it was an article or a presentation the other day — about contrast. It was a bunch of grayscale HMI, but just poorly done because the contrast, it made everything hard to see. It did the exact same thing that colored screens do. You have to really look in and pick out the detail you’re looking for.
Russel: We talked about this a little bit before we got on the mic, but the idea is to present information versus data.
Philip: That’s right.
Russel: From an operator context, you want to give them information, what they need in order to operate, and then from an analytical context, you want to give them data. Those two things need to be organized and placed in different places.
Philip: Yeah, they sure do, and just for that reason, because when you need the data to analyze something, that’s usually not the place that you want to be looking at all day, every day, to operate that area or that facility or whatever the case may be.
Russel: Yeah, you don’t want to wade through all of that in order to get to the things you need to do to operate.
Philip: Right. Those are things you wade through when you’re trying to diagnose a problem or figure something out, not just to run the line.
Russel: Exactly. I agree. In terms of working with the controllers, if you were going to give a SCADA person or somebody who’s aspiring to become a high-performance HMI guru some consulting about how to work effectively with the controllers, what advice would you give there?
Philip: That’s an interesting question. Work with them, not against them. That’s the first thing. Make sure that they know that you’re there to help them out, and to that effect, be there for them when you need them. [laughs]
I think I’ve gotten a lot less pushback from those people because we also provide a lot of the support. When they call and they need help, you help them, and you help them understand what they’re doing and what they’re using because they don’t know the tools or what all they can do.
You have to bridge that gap a little bit to explain to them what the tools are capable of, what you can give them, and just make sure they know that you’re on their team because, at the end of the day, we’re all trying to accomplish the same goal.
Russel: Exactly right. We’re all trying to be better at what we do, be safer at what we do. I agree. Just to say what you’re saying in my own language, I’d say what I hear you saying is, form a relationship. Try to really understand the person, and the job, and the struggle, and what they’re trying to achieve.
I think the challenges that…I’ve never said it this way before, but getting together and having this conversation is clarifying my mind a little bit. I’ve always said that sometimes when controllers are telling you something they think you need to know, it’s not very helpful, but what they know and are unable to articulate, is gold. It’s just really valuable.
Philip: That’s very, very true.
Russel: As we’re having this conversation, actually thought about this a different way. When they’re telling you, “Do this for me. Do this for me. Do this for me,” that’s not generally helpful, but when you can get them to say, “I’m trying to accomplish this,” that’s extremely helpful.
Philip: Absolutely. Like you say, they have so much knowledge about what they’re trying to do. Like you say, bridging that gap between what they know and what they need to get done, and see to do that, and understanding when they say, just like you said, “I need this. I need this,” understand what they’re really asking for and then find the right way to give it to them.
Russel: Yeah. I think being good at high-performance HMI is a lot about working effectively with the controllers in a way that you’re able to extract out of their mind the mental model that they have and use to operate the system, particularly if you’re dealing with somebody who’s been working with the system for a long time and has a mature model of how the system works.
The trick is, how do I get that out of their head and onto a screen in a way that pretty much anybody can see it.
Philip: That’s right, and in a way that pretty much anybody can use it, which obviously you don’t want anybody just going in and running the thing. I’d like to think that most anybody that you’d walk up to look an HMI that I’ve built, they’d be able to tell pretty quick that this is what this stuff is, just by looking at it, which is the whole goal.
Russel: Particularly if they had a background in pipeline operations.
Philip: Sure. That makes it much easier.
Russel: Just because you’ve seen all the graphics to fly an airplane doesn’t mean you know how to fly an airplane.
Philip: [laughs] That’s right.
Russel: Although, as an interesting aside, I watched a YouTube video. It’s been a while back, but it was a guy who had got flight simulator software and had been flying flight simulator software for years but had never actually flown an airplane.
He got with an instructor in a Cessna, same thing that he’d been flying with the flight simulator. With the instructor sitting in the instructor’s seat and this guy sitting in the other seat, he started up the aircraft, taxied out, flew the aircraft, circled the airport and landed the aircraft.
At the end of it, they asked the instructor how he did. He says, “Well, he did remarkably well.” He says, “He had a little difficulty on the landing.”
Philip: I could believe that. That just goes to show you technology has come a long way.
Russel: Which is very handy to know how to take an airplane off and fly it, but it’s very, very handy to know how to land it.
Philip: [laughs] That’s probably the most important part.
Russel: That, to some degree, it’s like riding a bike. You actually have to learn to do that through experience.
Philip: Yeah, absolutely.
Russel: All right. Look, I’m so glad I finally got you to come on.
Russel: Is there anything that you’d like to use as a tag to summarize what we’ve talked about?
Philip: I’ll summarize it in three takeaways, just about the high-performance HMI. Keeping it simple would be number one, and not to overstate that, you really have to unpack what simple means, because it doesn’t mean nothing but keeping it simple.
Really good to know the guys that you’re building this HMI for, the people who are going to use it. Build a relationship with them, and get to know what they need to see. Then, probably separating your operating contexts.
The controllers need to do one thing. There’s a bunch of other people that look at the system that need to do other things, and those screens shouldn’t live together. They have different uses and belong in two separate places.
Russel: I think that’s extremely well said. You guys out there in Pipeliners Podcast land, listen to this and write it down.
Russel: Once again, Philip, thanks so much for coming on board. I sure appreciate it.
Philip: Absolutely. Thank you for having me.
Russel: I hope you enjoyed this week’s episode of the Pipeliners Podcast, and our conversation with Philip Jones. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing.
If you would like to support this podcast, please leave us a review on Apple Podcasts, Google Play, Stitcher or whatever smart device podcast app you happen to use. You could find instructions at pipelinepodcastnetwork.com.
Russel: If you have ideas, questions, or topics you’d be interested in, please let us know on the Contact Us page at pipelinepodcastnetwork.com, or reach out to me on LinkedIn.
Thanks for listening. I’ll talk to you next week.
Transcription by CastingWords