This week’s Pipeliners Podcast episode features first-time guest Tony Alston of EnerSys Corporation providing insight on how to perform an API 1165 HMI review in alignment with the recommended practice for Pipeline SCADA displays.

In this episode, you will learn about the fundamentals of setting up HMI displays for controllers, the importance of performing a review to ensure that controllers can achieve situation awareness in each operating condition, the value of High-Performance HMI supporting pipeline safety and operations activity, and more topics covering pipeline SCADA and HMI.

API 1165 Review: Show Notes, Links, and Insider Terms

• Tony Alston is a SCADA developer and software engineer for EnerSys Corporation. Connect with Tony on LinkedIn.
  • EnerSys Corporation is the sponsor of this month’s Pipeliners Podcast episodes. Find out more about how EnerSys supports pipeline operations compliance, audit readiness, and control room management through the POEMS software suite.
• 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 an advanced HMI system that improves a pipeline operator’s situational awareness during normal and abnormal situations. High-Performance HMI takes available data and presents it as information that is helpful to the controller to understand the present and future activity in the pipelines. (Listen to Pipeliners Podcast Episode #5 covering the topic of High-Performance HMI.)
    • 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.
      • Listen to Pipeliners Podcast Episode #67 for Russel Treat’s referenced discussion of Plato’s shadows on the wall relating to 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.
• Control Valves regulate the flow of product in a pipeline. For instance, a control valve could be set to target a specific pressure or could control mixing to target a specific temperature.
• Shutdown Valves stop the flow of product in a pipeline. They are commonly used to stop flow when a leak is detected or when an adverse operating condition is detected.
• PSVs (Pressure Safety Valves) provide relief in the event of a gas pipeline leak. PSVs are designed to quickly release gas from the pipe to avoid overpressurization and potential pipeline safety incidents. PSVs are activated when the pressure in a pipe exceeds the set pressure limits.
• ESD (Emergency Shut Down Systems) are high-powered control systems designed to protect people, pipelines, and the environment in the event of a pipeline operating beyond set control limits.
• O&M (Operations & Maintenance) is a comprehensive approach to performing pipeline tasks related to the operation and maintenance of gas and liquid pipeline systems. A robust O&M program provides personnel with the knowledge and understanding of each situation to enable them to correctly assess the situation and take corrective action.
• The CRM Rule (Control Room Management Rule as defined by 49 CFR Parts 192 and 195) introduced by PHMSA provides regulations and guidelines for control room managers to safely operate a pipeline. PHMSA’s pipeline safety regulations prescribe safety requirements for controllers, control rooms, and SCADA systems used to remotely monitor and control pipeline operations.
  • Point to Point verification confirms that input or output from each field instrument is accurately and reliably reflected in the SCADA information presented to the controller. [EnerSys offers the PointMgr software module to manage this process.]

API 1165 Review: Full Episode Transcript

Russel Treat: Welcome to the Pipeliners Podcast, episode 205, sponsored by EnerSys Corporation, providers of POEMS, the Pipeline Operations Excellence Management System, compliance and operations software for the pipeline control center to address control room management SCADA and audit readiness. Find out more about POEMS at EnerSysCorp.com.

[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. I appreciate you taking the time, and to show that appreciation, we give away a customized YETI tumbler to one listener every episode. This week, our winner is Monica Johnson with Centurion Pipeline. Congratulations, Monica. Your YETI is on its way. To learn how you can win this signature, stick around till the end of the episode.

This week, Tony Alston, SCADA developer at EnerSys Corporation, is joining us to talk about performing an API 1165 HMI Review. Hey, Tony. Welcome to the Pipeliners Podcast.

Tony Alston:  Hi, Russel. Thanks for inviting me here today. I always enjoy listening and hope to share some insight with you.

Russel:  For the listeners, Tony and I have been talking off my mic a little bit as we’ve been getting prepared to record. He was more drafted than volunteered to come be a guest on the podcast, but he’s a wealth of knowledge. I’m sure the listeners will enjoy hearing from him. I appreciate you coming on board, Tony. I think this will be a fun conversation.

Tony:  Yes, sir. I thank you very much.

Russel:  [laughs] Listen, before we dive in, why don’t you tell us a little bit about your background, where you come from and how you got into pipelining, and what you do?

Tony:  My background coming into the pipeline is a little odd. I started off as a database administrator. I was hired on to help facilitate a database of SCADA information, to help get it organized.

One day, I happened to see the main control room of a pipeline operations center. I was so fascinated, like “What is that?” I inquired. “Show me what these guys are doing. Explain to me what they’re seeing” because a database guy is all about numbers. Here we are, looking at something that’s completely visual. That was a fascination that started my SCADA environment.

Russel:  How long have you been working in SCADA now?

Tony:  A little over 10 years now. On and off, still with databases but more devoted specifically to SCADA.

Russel:  I asked you on so we could talk about API 1165 and in particular doing an API 1165 review. I know you’ve done some of that. Maybe to set a little context, it’d be good to just ask you what is API 1165?

Tony:  API 1165 is what operators need to gain confidence in what they’re seeing on the screen so that they know what’s happening in the field is actually relayed to what they’re seeing on the screen.

Russel:  That’s really well said. That is a simple statement, and there’s a whole lot bound up in that. Making sure that an operator understands what they’re looking at right, what the graphics mean and all that kind of stuff, and having confidence that those graphics are saying the right things, it’s no small thing in a control room.

Tony:  That’s right. There are a lot of things happening at once. There are a lot of pieces in the background. It can be complicated and get really hairy really quick. API 1165 takes all of that encompassed and puts it in a manageable frame.

Russel:  That’s extremely well said. How is 1165 related to pipeline safety?

Tony:  It keeps control room operators from falling into what we like to call an HMI trap. An HMI trap would be where an operator has too much information, too many alarms, too many flashy things happening on a screen, to where relevant information that’s important at the moment can get hidden behind all of the other things. Your attention is drawn away from what you actually need to see.

Russel:  Again, that’s very well said. One of the challenges around well-designed HMIs is that on the surface they appear very simple. That’s if you’re following a 1165 is still with intent. You’re trying to get all of the noise and all the complexity out of the way so that what really matters can be seen and understood quickly.

Tony:  That’s right. I agree with you.

Russel:  That is not a simple thing to do, right?

Tony:  No, sir. That’s probably one of the more challenging things of pipeline screen display.

Russel:  Without a doubt. You’ve been doing this long enough like me, that you’ve been involved with some migrations from the old HMIs to the more modern, what I would call an API 1165 HMI designer, or what could also be called a high-performance HMI design. What does that migration involve? In your opinion, what do you think is the most challenging bit?

Tony:  It involves updating what you currently have to something new. The challenge is to bring your operators alongside that change so that they are not just exposed to it raw and are trying to figure out a new system while the pipeline is in operation.

Russel:  Do you think the controllers resist change?

Tony:  I think historically people themselves resist change. A pipeline operator is no different. Having that mindset, yeah, a pipeline operator is going to resist a change because they are used to operating their pipeline assets a certain way, and to introduce a new way to do it is going to impact them as far as their confidence and their ability to manage their resources.

Yes, it’s going to have a direct impact on operators. What you need to do as a migration is to gently introduce them with pieces of new technology, or new screens so that they can feel like they’re part of the system now where they know how to operate their screens.

They know what it’s going to do. They know how to expect maybe new alarms to come in, where they’re going to come in at, new screens, new graphics, new ways of displaying information.

Russel:  I think something as simple as just a valve and the animation and alarming around a valve, you think of a valve, it’s a pretty simple thing, right? It’s either open or it’s closed.

That’s a gross oversimplification because what you really want to know is when I send an instruction to open, has the device received the instruction? Is it moving? Is it finished moving? And, when it finished moving, did it move all the way into the position it’s supposed to be in?

Tony:  That’s right.

Russel:  If none of those things happen, then I want feedback to tell me that what didn’t happen that should’ve happened. Now all of a sudden, okay, that’s helpful. Then you get into all these issues about, well, there’s a lot of different ways to automate a valve to do that exact thing.

The animation might always look the same, but there might be 15 different ways to do the actual automation. Does the controller need to know how the automation actually works? Well, maybe, maybe not. Those kinds of things tend to make all this really complicated.

Tony:  That’s correct.

Russel:  I always have said that, at least in my experience, that the controllers are a wealth of knowledge, they know so much about how the process behaves. They all have some image in their mind that they have to help them run the process or run the pipeline, right?

Tony:  That’s correct.

Russel:  The trick is mining for that data in a way that a SCADA tech can actually build graphics that support and facilitate that way of thinking about things.

Tony:  That’s right. Also, being an HMI developer, you’re not going to know what the operator’s going to expect to see. Having the coordination between an actual controller and your HMI developer is a big plus because that information can come from the controller to the SCADA technician, and pass on some relevant information.

Russel:  That’s one of the places where API 1165 — if it’s well understood in an organization — can be extremely helpful. It can create a mechanism for having that conversation.

Tony:  I agree.

Russel:  It raises all the right kinds of questions.

Tony:  I agree.

Russel:  I know that you’ve been involved. What are the things you need as an engineer? What are the things you need in order to implement an 1165 approach, beyond the standard itself?

Tony:  You need a good design document, number one.

Russel:  What’s in a design document? What content would it have?

Tony:  That’s a very good question. A design document is your roadmap to get from where you are to where you want to be, in accordance with the 1165 standard.

Russel:  What kinds of things would you expect to see? If I’m a pipeline operator and I’m going to create a design document, what things would I expect to see in that design document?

Tony:  You would see things like how your graphics should be laid out, how your screens should be laid out. Again, these are guidelines, they are not “you have to follow this verbatim.” They’re guidelines. A SCADA design document should have information about the objects that are going to be on an HMI screen, such as the orientation, any animation, the size, any information that’s going to be related to that object.

For instance, if you have a valve, what are the states that the valve is going to be displayed on your screen? Are you going to have something as simple as a color change, or are you going to have something as simple as the HAT on the valve changes, so that you know that that valve is in transit?

What are you going to do if an error pops up, the valve doesn’t open, or it doesn’t shut, or there’s an impediment in the valve that keeps it from operating? How are you going to relay that information back to the operator?

Russel:  You could continue to pull that onion, and there’s all the things around the faceplate, how you interact with the valve to instruct it to do different things?

Tony:  A valve is a pretty granular piece of the whole pie. You can take that same mentality and apply it to a station, and then apply that same mentality to your entire pipeline from beginning to end.

Russel:  There’s a large library of objects. A valve is not a valve. You got block valves, and gate valves, and gas-operated valves, and motor-operated valves, and you’ve got flow control valves, and pressure control valves, and pressure regulators. All those are valves, and they all have different properties. They all have different interactions.

Tony:  That’s right.

Russel:  Like a lot of the things, the devil’s in the details.

Tony:  That’s correct. The sky’s the limit on what you can implement in your pipeline. The trick is to be consistent and to follow the guidelines that are published so that when the dreaded audit comes around, you know you’re operating your pipeline the same from beginning to end. You’re also operating the pipeline the same from operator to operator.

Russel:  That’s a mouthful right there. That’s a lot. So, I want to talk some about the API 1165 review. What we’re seeing with our customers and in the audits is that the regulators are digging into more detail around specifics of things around alarm management and HMI implementations, and so forth.

I certainly know that we’re seeing a lot more questions about, “Well, how do you know that this HMI complies to 1165?” We’re seeing more of that kind of question. What is the API 1165 review? Why, in your opinion, is it important?

Tony:  It’s important because it looks at a lot of things. Number one, a design document. It takes what you have and compares it to what you said you were going to have, and what was actually implemented.

It takes it through all of its paces and says, “Okay, I sent a command to do something in the field. Did the command get there? If it did, what’s happening? Is what’s happening what I’m expecting? If it’s not, what am I presented with? How do I remediate it? How do I deal with it? Where do I go from here?”

Russel:  This is one of those things that, for somebody who’s worked around HMIs, it’s self-evident. For people who have not, it’s a mystery. If you look at an HMI it’s like, “Oh, I click this button and the valve opens,” but that’s five percent of what’s really going on.

Tony:  That’s right. There’s so much in the background with that mouse click. A lot of people are really surprised.

Russel:  I think that’s very true. That’s very true. There’s this other thing about, “Okay, I made the mouse click, and something was supposed to happen, and then I should get some feedback,” but it didn’t happen. “Well, I won’t feed it.”

I’ve seen many HMIs. You don’t tend to come across this as much anymore. HMIs are tending to mature, but I’ve seen a lot of HMIs where it was one click and the valve was supposed to be open, but there was really no feedback. It was fire and forget.

The important thing about a good HMI is there’s lots of feedback for the operator to verify the processes occurring the way it should be occurring, and giving them lots of information when the process is not occurring the way it should be occurring.

Tony:  That’s true.

Russel:  That’s where the hard part comes, is all the complexity around that.

Tony:  Correct. That’s why the review’s that important because of that level of complexity.

Russel:  How do you verify all those abnormal behaviors and that you’ve got that consistently and correctly implemented in the HMI?

Tony:  There’s many ways to do that. The way I’m familiar with it is old school. There was a guy in the field while we were in the control room. There was verbal communication between the control room and the guy in the field.

When we set the command, the person in the field validated that they got the command, and something in the field was happening. Whatever was sent to it is actually happening. You had that line of sight, so to speak. Extended eyes where the control was validated by somebody as this is actually happening.

We went through the whole thing of fully open, fully closed, send a command to open. The guy in the field pulls the power. What’s it going to do? Did the control room get the alarm? Did the screen reflect that? All of the real-life scenario things that you didn’t want to happen were tested in real-time. Did the HMI in the control room actually reflect the true conditions in the field?

Russel:  Did you do that for every single site, or did you do it for a single site and then apply that to many other sites?

Tony:  Unfortunately, we did that for every single site, for every alarm, for every ESD, for every valid situation where any kind of incident that could happen was documented. You didn’t want a runaway pipeline that you couldn’t operate.

Russel:  [laughs] The reason I’m standing on this a little bit, Tony, is I think whenever you have this conversation with an operator that doesn’t really understand the consequences of not getting this kind of thing right, there’s a large level of effort associated with this.

There’s a potential significant interruption to operations when you’re doing this kind of thing, but they’re absolutely critical. Are you doing this as part of an upgrade, or are you doing this simply as an 1165 verification process?

Tony:  It was actually in both. We would do the 1165 verification, at least once annually. Any new assets that were brought on to the operators were tested rigorously with the same measure.

Russel:  That’s interesting. That’s a big level of effort. How would you work that into your schedule to be able to get that done? I’m really asking that question more from a field perspective. How did that work? I guess you’d have to get that into your routine O&M schedule around other things that you’re doing.

Tony:  It was usually done during plant maintenance. Each facility or pipeline had scheduled maintenance along the line during some part of the year, and we would schedule with that maintenance. When that valve station was going to be down, or that pump station was going to be down, or this pad was down, we would send an extra guy to the facility as the “SCADA eyes” and do a lot of the things at one time.

Russel:  I think there’s requirements that you’ve got to stroke every valve at least once a year.

Tony:  That’s correct.

Russel:  So, if you’re going to be doing the O&M to stroke the valves, that’s a good time to be verifying that all of your SCADA and automation is working correctly beyond just the mechanical function of the valve.

Tony:  A lot of things were beyond mechanical function of the location. We also did the security, the fence alarms, the building alarms, fire alarms, things like that. There was a lot more encompassing in our 1165 maintenance, than just stroking a valve to make sure it does what it does.

Russel:  Thank you for that. It’s good to point all that out. I guess the point I was trying to make is that in order to minimize the workload, you’re doing that around other routine maintenance activities that needed to occur.

Tony:  That’s correct. Yes.

Russel:  You already got somebody there, they’re already doing things, and they’re going to have to do it. They’re going to have to do these things anyways, because they’re required for routine maintenance, and consequently that minimizes the impact on operations.

Tony:  That’s correct.

Russel:  Wow.

Tony:  Anything that you can combine into something else is probably better off for you.

Russel:  That’s a big level of effort. That’s a big level of effort. I would say that an operator’s got…

Tony:  It takes communication between several of your departments, either scheduling, and your control room, or it starts at the management level. It says we need to coordinate these things so that we minimize our downtime and can maximize the downtime that we do have.

Russel:  I’ve worked with at least one other large operator that when the Control Room Management Rule was coming out, they took a look at all of their routine O&M around measurement, and metering, and PSV checks.

They modified all that to include appropriate point-to-point and HMI verification as part of those tasks. That ended up minimizing the network load increase because they just added stuff they were already doing. It became, “Well, we just need to coordinate with a…I’m going to go out there and I’m going to do a five-point test on a meter.”

I want to call the control room as I’m doing that, and ask them to sit there and do their check-offs and make sure they’re seeing everything correctly at the same time that’s a minor thing versus going out there and doing that as a special requirement, where it’s a whole new set of recurring work.

Tony:  Yes, it took effort.

Russel:  The management comment is right on-point because you’ve got to manage schedules, you’ve got to manage multiple departments, you’ve got to manage their policies, and in particular, you got to manage their procedures, and update them, and coordinate them. The regulators love good paperwork. That gives the regulator’s things to look at. [laughs]

Tony:  The more paper that you can present to them, showing that you are following the rules, the happier your company will be, in the end, guaranteed.

Russel:  That’s very true. I’d like to ask this question to wrap the conversation up. What do you think all pipeline operators, meaning anybody working for a pipeline, ought to know about API 1165, and the control room, and the screens? What should they all know?

Tony:  What should they all know? We all want to be better and safer at our jobs personally. API 1165 is easy. It is tedious to implement. It’s not a quick change. Just because it looks simple, and a lot of things are going on in the background, it doesn’t mean that it is simple.

There are pieces to an HMI screen that happen in the background that operators really don’t see, and they may not even be aware of. That’s okay. Just because you don’t know what your screen has waiting for you, doesn’t mean that you don’t need to implement 1165. It is a method that improves your safety, the reliability, and the property of a pipeline.

Russel:  I would say that the thing I want people to know about is this is a really well-designed HMI, on the surface seems very simple, but simple is very difficult to achieve. It’s simple for the operator, but achieving that is not simple. The other thing that I would want everybody to know is that there’s two key things that a controller really wants.

One is they want consistency, and they want to know that if I have this valve and I do this kind of thing, I always get this result. They want to know consistency. They want to have confidence in that HMI because they rely on it. They rely on it to operate the pipeline, and they rely on it to achieve their daily objectives without doing harm.

Tony:  That’s right. The HMI is the operator’s eye in the field. They need to have 100 percent confidence in what they’re using is 100 percent reliant.

Russel:  Absolutely right. I did an episode some time ago, and I was talking about Plato’s story about fire and shadows on the wall and how the HMI is the shadows on the wall.

We’re relying on that HMI to be our eyes to the field, but we’re working within the limitations of what the software tools can do. In this day and age, it’s not so much about software, what software tools can do because they do a lot. In this day and age, it’s about what the technicians can do to actually make those shadows meaningful. It’s a good place to stop.

Tony, before we wrap up, I have to ask the question because I know you’re a little bit nervous about doing all this. How was this? Was this fun? What’s your take on being a podcast guest?

Tony:  This is actually fun. I enjoyed myself. I got to talk about a little bit of experience and opinion. It would be worth doing again.

Russel:  There you go. See? For all of those you out there that think you have something of value to share with other pipeliners, reach out to me. It’s not as hard as what you might think. [laughs] Hey, Tony. Thanks a lot, man. I appreciate it. You have a good day.

Tony:  Thank you.

Russel:  I hope you enjoyed this week’s episode of The Pipeliners Podcast in our conversation with Tony. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinerspodcast.com/win to enter yourself in the drawing.

If you’d like to support the podcast, please leave us a review on Apple Podcast, Google Play, or on your smart device podcast app. You could find instructions at pipelinerspodcast.com.

[music]

Russel:  If you have ideas, questions, or topics you’d be interested in, please let me know on the Contact Us page at pipelinerspodcast.com or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.

Transcription by CastingWords