This week’s Pipeliners Podcast episode features first-time guest Stephen Swanson discussing process safety management (PSM) and pipeline alarm management with host Russel Treat.

In this episode, you will learn about the opportunity to integrate process safety management and alarm management, the different needs of PSM and alarm management, the cultural challenges associated with knowledge and process transfer to a new workforce, and more topics.

Process Safety Management & Alarm Management: Show Notes, Links, and Insider Terms

• Stephen Swanson is a Process Safety Engineer for Noble Energy. Connect with Stephen on LinkedIn or through his email, skswanson37@gmail.com.
  • Noble Energy is an independent oil and natural gas exploration and production (E&P) company.
• Process Safety Management (PSM) refers to a set of interrelated approaches to managing hazards associated with the process industries and is intended to reduce the frequency and severity of incidents resulting from releases of chemicals and other energy sources.
• Alarm Management is the application of human factors along with instrumentation engineering and systems thinking to manage the design of an alarm system to increase its usability.
• Devon Energy is a company engaged in hydrocarbon exploration in the United States.
  • Enlink Midstream Partners is a U.S. midstream energy company that transports, stores, and sells natural gas, NGLs, crude oil, and condensates to industrial end-users, utilities, and other pipelines. Enlink Midstream is a leading midstream provider formed through the combination of Crosstex Energy and substantially all of the U.S. midstream assets of Devon Energy.
• Process Hazard Analysis (PHA) is a set of organized and systematic assessments of the potential hazards associated with an industrial process.
• Enogex is engaged in natural gas gathering, processing, transportation, storage, and marketing. 
  • In 2013, it was decided that Enogex would be merged with a portion of CenterPoint Energy’s operations in a limited partnership to be called Enable Midstream Partners.
• Operational Risk Management is defined as a continual cyclic process, which includes risk assessment, risk decision-making, and implementation of risk controls, which results in acceptance, mitigation, or avoidance of risk.
• Asset Integrity is the ability of an asset to perform its required function effectively and efficiently whilst safeguarding life and the environment.
• H2S is a dangerous gas that can be present at many types of workplaces.
• Piping and Instrumentation Diagram (P&ID) is a graphic representation of a process system that includes the piping, vessels, control valves, instrumentation, and other process components and equipment in the system.
• Well Pads are the area that has been cleared for a drilling rig to work on a plot of land designated for natural gas or oil extraction.
• Human Machine Interface (HMI) is the user interface that connects an operator to the controller for an industrial system.
• The trio from Marathon are Dan Sensel, Jason Dalton, and Kyle Miller, who are all regular guests of the Pipeliners Podcast.
• Standard Operating Procedures (SOPs) is a set of step-by-step instructions compiled by an organization to help workers carry out complex routine operations.

Process Safety Management & Alarm Management: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 96, sponsored by EnerSys Corporation, providers of POEMS, the Pipeline Operations Excellence Management system, SCADA compliance, and operations software for the pipeline control center. 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:  Thank you for listening to the Pipeliners Podcast. We appreciate you taking the time. To show that appreciation, we’re giving away a customized YETI tumbler to one listener each episode. This week our winner is Cody Allen with Holly Energy Partners. Congratulations, Cody, your YETI is on its way.

This week we have Stephen Swanson joining us. Stephen is a Process Safety Engineer. We’re going to visit about PSM and alarm management. Stephen, welcome to the Pipeliners Podcast.

Stephen Swanson:  Thank you, Russel. I’m very glad to be here.

Russel:  Let’s start out. Why don’t you tell the listeners a little bit about your background? What you’ve done, what you’re doing, that sort of thing.

Stephen:  Absolutely. I started my career as a jack-of-all-trades engineer in the oil and gas business for a consulting firm. Following that, I went to an operator, Devon Energy, where I first entered a process safety dedicated role, if you will.

I started out doing process safety as part of engineering consulting, doing PHAs for our customers and so forth. Different process safety related technical tasks, and then went to work for Devon Energy. I was stationed at a pretty large gas plant in North Texas by Fort Worth.

From there, I worked pretty much with gas plants for the next four to six years. I went away through a merger to Enlink Midstream Partners. Devon merged their midstream stuff with a company called Crosstex out of Dallas.

Then from there, I went to Enable Midstream Partners in Oklahoma City. From there, moved to Noble Energy, where I’m currently managing the process safety program for the Colorado Denver Julesburg Business Unit on the upstream side of the business.

Russel:  A lot of experience with facilities and a lot of experience in process safety management. That’s what I asked you to come on to talk about because we had the opportunity to do a little work together and had an interesting sidebar conversation. I thought maybe some [laughs] other people would like to listen to it.

Why don’t I start with this question? What is process safety management? Why is it important?

Stephen:  I look at process safety as mostly operational risk management mixed with what some may call asset integrity or asset reliability with a specific focus to safety rather than purely optimal operations. It’s less focused on optimal operations and more focused on safety-related reliability, keeping it in the pipe.

Russel:  The way I would frame process safety management, and I am by no means an expert, is process safety management is you look at a facility or a system and you ask a whole bunch of questions about what could go wrong. You make sure that the facility or system can handle that mechanically if it goes wrong. The systems in place will operate and cause a safe outcome even when you have an upset.

Stephen:  Yes.

Russel:  That to me is simplistically. It’s engineers design a facility to do a job. Then somebody needs to come along behind them and look at their design and say, “Okay, that’s fine. But what are all the things that could go wrong? How do we make sure that that abnormal operation is manageable?” Fair enough?

Stephen:  I would say that’s absolutely correct. I would add that we do that with an emphasis on the risk associated with the hazards of that process versus the effort necessary to make it safe and try to achieve as low as reasonably practicable likelihood of an event.

Russel:  Meaning that if I’ve got a facility that’s got H2S, then I’m going to handle that with a particular level of care than if I have a facility that doesn’t have H2S.

Stephen:  A very good example. Yes, sir.

Russel:  I’m a bit of an alarm management guy. I think a lot of times that people get alarm management and process safety management confused. We recently went through some projects, we were workshopping things, and we got into this conversation about how is process safety management and alarm management different.

I’m going to try and give you a definition of alarm management. I would say alarm management is the process of reviewing on a system, to make sure that I get alarms before I get an upset, and I get them in a way that as an operator I can affect change before I get to the upset. Does that sound reasonable to you, given what we did together?

Stephen:  Absolutely. I think the confusion happens at the end of what you just said. It’s where that scope ends that process safety begins, once the upset is not avoided, right?

Russel:  Yeah. If you had a perfect system, you’d never get an alarm. If you had a perfect alarm system or program, you would never have a process safety event.

Stephen:  That’s absolutely true. If you had a perfect alarm system, you would not need process safety-related automation, in theory.

Russel:  Yeah. In theory, in theory. We’re not saying you don’t need it. You absolutely need it. I think one of the things that’s interesting is the way that they’re the same.

When I start a process safety management process, or I start an alarm management process, I’m looking at the P&ID drawings, I’m looking at the safety matrix, I’m looking at the cause-effect diagrams, and I’m looking at the process, and I’m walking the process out.

In that way, doing an alarm management process and a process safety management process are very similar. You’re asking, I think, very similar questions. You’re asking, well what happens if, and then how is that handled?

Stephen:  The analysis from my perspective, especially after what we did together in some previous alarm related rationalization conversations, is almost verbatim conversation. You’re having a sensing device by sensing device, operating parameter by operating parameter, “what can go wrong?” conversations, and what are the consequences of those upsets if you will?

Russel:  How are these two things different?

Stephen:  These two things become different when you start talking about the reliability of the desired…I’m going to use the term safeguarding because that’s what we typically refer to in the process safety world.

Whatever the barrier is, between you and the upset, or you and the hazard, you have different considerations for how reliable those safeguards are, and you have different considerations for how you assess the severity of the upset. From my perspective, in the process safety world, the consequences are more severe, and that drives us to have much more reliable safeguarding.

In the alarm world, you’re relying exclusively on human intervention, which has to account for human error. On the process safety side, we almost completely ignore what humans can do to prevent upsets, and assume it’s not going to work, and provide mechanical devices to protect us, in case humans can’t respond in time.

Russel:  I think that’s where it starts getting really complicated. When you’re talking about alarm management, one of the questions that I always ask is, what’s your operating philosophy?

Is your operating philosophy, “We’re going to let the mechanical safeties trip and our response is to get the process back online,” or is your operating model, “We’re going to operate without ever hitting a process safety trip?” Most people will say, “We want to operate without ever hitting the process safety trip.”

When you start driving through the questions and doing the analysis, what you often find is that the automation system, the HMI, and the way the alarms are set up or configured don’t give you any effective means to react or respond. You’re driven to the trip just because things move so quickly or because the trip is so close to where the alarm is.

Stephen:  Yes. That’s quite common. I would almost say that the response time provided with a complete lack of clarity on what to do when that alarm comes across are the two big things that I see.

Russel:  [laughs] Yes! It’s easy to get thrown to either the process safety system will trip and everything’s okay or I’m going to ignore the process safety trips and everything in my alarm system is a critical alarm. It’s hard to navigate what am I really trying to do in alarm management as opposed to safety process management.

I’m looking at the same process but where process safety management is looking at, I want to make sure that nothing mechanical can actually go wrong. Alarm management is “I want to maintain control of the process.” When I have something moving towards an upset, I want to know, I want to get information, and I’ll be able to take the action to get it back.

Stephen:  Correct.

Russel:  In your experience of doing alarm management, how much of implementing a good alarm management program is doing the rationalization versus how much of it is re-evaluating your entire approach to automation?

Stephen:  I would say it this way. It’s almost like diet and exercise. It’s 85 percent diet. It’s 85 percent landing on what your operating philosophy is going to be.

Then the exercise is doing the rationalization against the philosophy you’ve landed on and organizations understanding the philosophy you described of operating and using your alarming to operate without shutting down, using alarming to keep the process in control.

Understanding really what that means is a significant learning exercise in my experience, especially on the upstream side versus the midstream side of the business.

Just because, from a process safety management, that kind of analysis, that kind of looking at your operating philosophy, because of the PSM rule, the midstream side of the business, gas plants, pipelines, they’re further along in the upstream side of the business.

Russel:  They’re definitely culturally I think the industry’s further along. However, I still think there’s a long way that they have to go.

The comment you made, I think we need to unpack that a little bit because it’s a very subtle thing. Understanding what it really means, what’s really required to put in place an effective alarm management program such that I operate without ever hitting my process safeties, that is a big deal.

Stephen:  It really is.

Russel:  It’s one of those things that I think everybody gives intellectual assent to the notion without really understanding how deep that goes when you start talking about “how am I actually going to operate a system.”

Stephen:  I’ll just give you an example from my experience. Your first rationalization exercise of your existing alarming against that philosophy, you find out that most your alarms don’t help you get to that goal at all the way they’re currently set up.

Russel:  How would you characterize what you tend to find in the way your alarms are set up?

Stephen:  From my personal experience, you see things like almost no response time for a human being. You sometimes don’t see the automation necessary for human intervention remotely.

For example, there can be situations where the only action that could be taken to avoid the shutdown is to send a man to the spot and make a correction. On the upstream side of the business, that’s much more difficult than in a gas plant where everybody’s on-site all the time.

Then, combine that with almost no reaction time even if that were possible because most of our critical alarming, the things we would consider critical alarm at the time, occur when the shutdown occurs. That’s what historically we’ve been most concerned about. We need to know what’s shut down so we can head out and turn it back on.

Russel:  Culturally, that’s where we’ve lived. The best example in any of this stuff is always pressure. Most of the processes that we deal with are pressure-centric processes. We’re trying to manage and control pressure.

Just to take simple numbers, if I’ve got a system and its max operating pressure 1,000 PSI and I have the alarm set at 975 and I operate most of the time at 970, how much room do I really have to do anything?

Stephen:  Virtually zero.

Russel:  If you say, “I want to be able to run this system so that if I do have an increase in pressure, I have an ability to adjust it,” then I’ve got to look at how quickly does the pressure move and what are the things that I could do to lower pressure? Do I have the automation and the communications to allow me to do those things remotely in a time frame that matters?

That’s an entirely different conversation than what we have historically had around alarm rationalization.

If I made Stephen king of the world [laughs] and I said, “Stephen, you’re going to get to start a brand new greenfield project,” what would you do differently in terms of the way systems are designed and worked through PSM and worked into operations?

Stephen:  I think alarm rationalization can be the bridge between optimizing your operations and doing process safety well in that that exercise of looking at your alarms, looking at which ones aren’t working for the philosophy as we’ve described it of preventing upsets before the upset occurs.

If you exercise that muscle and use the data that that gives you, you not only tweak your alarming so that you can be more effective at curbing upsets, but you identify things that a good process hazard analysis in the process safety world can miss, where you have a design shortcoming.

Like on pressure, if your system’s designing to 1,000 PSI and you’re going to desire to operate at 970, maybe that’s too close and it’s unfeasible. You’re shutting down too often. You really need to evaluate the next time I design a facility like that, do I design a 1,200 pound system?

Russel:  Or do I design it to operate at 970 PSI?

Stephen:  Or can you upsize so that you can get the same flow at lower pressure? Whatever the answer is to stabilize and bring your process in control.

I’ve had this conversation too many times where I’m like, “How did the PHA not catch this?” I’m like, “The PHA can’t tell you if it’s going to operate well or not. All I can tell you is it’s going to be safe. You may be shut down all the time. But it’s going to stay in the pipe.”

The PHA process doesn’t have time to evaluate every contingency like that, especially in a situation on the upstream side of the business where you don’t always know exactly the conditions that are going to come out of the ground.

Russel:  That’s not just upstream. You find that in midstream, too. You got people bringing wells on and taking wells offline. That’s just the nature of operations is I get what is given me. I don’t really get to control what is given to me.

Stephen:  It’s true.

Russel:  When I noodle on this question, and I think it’s a really interesting and valuable question to noodle on, I don’t come up with a clean answer. Really, the way we do it right now is the design, the PSM, and the alarm management are three separate processes done at three different times. Ideally, I’d like to do them all on the front end.

What you were saying before, there’s tradeoffs. If I make certain changes in the process design or in the safety design, then that has tradeoffs for the alarm design and vice a versa. They all impact each other.

Stephen:  Absolutely.

Russel:  What I’m wondering is how would you actually get a company to do that? How would you actually get the engineering? I’ve had a similar conversation about measurement in facilities where: “We don’t need custody measurement. We just need process.”

Stephen:  [laughs]

Russel:  Then later we come along and we go, “Nope. In fact, we need custody.” Modifying to get the custody is prohibitively expensive where if I’d just put in a little bit longer straight run of pipe, I could have made that modification easy.

Stephen:  [sighs] That becomes the big trick. You have to develop a culture of learning from those mistakes that also becomes difficult.

A lot of people in the position where they’re doing the types of analysis necessary to identify that problem and fix it on the front end of a project can be in situations where they don’t have the time to actually put that cost analysis together, that missed opportunity analysis together.

Russel:  The pressure is to get it up, get it running, get it flowing so we have revenue. With revenue, we can do other things.

Stephen:  That’s exactly right. I’m trying to think through a way.

I think you have to start with an initial pass of the design on the upfront. I almost think in a perfect world, you do it in pieces. You could probably accomplish it PHA style by breaking your process apart by node. Before you do the detailed design work and size things and size lines, put your process together node by node and understand the functions that each node is desired to bring.

Knowing your inlet and outlet of the process, you can take just those key facts. I know I need to turn this stream into these three separate streams. I know what I’m getting is at this pressure and this temperature. I think you could reasonably, if you had the frame of mind ahead of time, think about what the upper and lower safe bounds. Then I’m thinking through things like liquid flow rate.

Say you’re doing two-phase separation only. You know what the liquid composition of that stream is. You know how fast that vessel’s going to fill up pretty much. You may not know the exact dimension on that vessel at this point, but you can get a pretty good ballpark.

Then you can know, “This is where I need to be. This is where I start having problems. This is my fill rate. How much time do I need to catch a problem before liquid carries over that vessel?”

Then you could work from desired operating point up to your initial upset, upper and lower bounds, and then to your safe upper and lower bounds. Then you could set your alarming and your operation accordingly.

For those listening that have been in PHAs, I think most of that is talked through with just that alarming component missing. Things like adjusting safe upper and lower limits on pressure for process equipment, if you find a reason to change those late in the game, they can really bust budgets and things of that nature.

Russel:  It really upsets the apple cart. [laughs] Those things are easy to change when you’re working on paper.

Stephen:  Exactly.

Russel:  [laughs] They’re not easy to change once you’re working with metal.

Stephen:  That’s very true. If we could move that thought process upstream in the design process, then I think we’d really have an opportunity to execute this vision that we’ve been describing here. While they’re different, they overlap in this arena.

Russel:  As we’re sitting here talking, I’m recalling a conversation that I had with the trio from Marathon about how they work with business development and how they go through the design process when they’re designing a new pipeline.

What are the issues around size and operating pressures and where you put pumps? How that varies depending on the product you’re going to move. The business development guys think they know and then it changes because the customer commitments change.

All those things are moving targets. You’ve got all those factors that impact all this. What I see very commonly is doing a good job of alarm management is very often constrained by the way the physical process is built.

That’s problematic. We design how we’re going to operate after we’ve already designed what we’re going to operate. Those two things need to be different parts of the same conversation.

Stephen:  That’s a good way to put it.

Russel:  I don’t know how you get there culturally. I’m with you. I am not aware of anybody who has done a PSM and an alarm management process concurrent.

If there’s anybody out there that’s done that, I’d love to hear from them. I’d like to hear what your experience was. Even if we can’t get you on the show to talk about it, [laughs] I’d still like to know. I’d like to know if this notional idea actually holds water or not.

Stephen:  I would, too.

Speaking specifically in the arena I’m in now, back into the upstream side of the business in these U.S. onshore shale plays, most of the companies that are executing successfully in these shale plays are building cookie-cutter facilities where they’re pretty much building the same facility in multiple spots.

Russel:  Their facilities in many ways are very much like what a classical gathering company would do. They’re doing a lot of what gathering would have historically done. They’re doing it right at the well pad or very close to the well pad.

Stephen:  Honestly, this is true from the midstream gas plant world that I came from, too. You build virtually a very similar gas plant every time or virtually a very similar production facility every time.

If you do your PHA well at the beginning of that process, whenever it was, you have an opportunity because as you get better, the PHA process becomes less and less time constraining each time. You have less and less to PHA from scratch.

If you can capitalize on that, what you end up with is more and more opportunity to plug the alarm rationalization and the alarm-tuning conversation in on the front end of design because the other piece of your effort is getting lower and lower.

Russel:  In fact, we’ve had that conversation in-depth in our company. Without getting too deep into it, we have an alarm management tool. It’s designed specifically for pipelining.

We added to it the ability to copy and paste. The reason we did that is that none of the other tools that we could find off the shelf did it. In pipelining, there’s a lot of replication.

You don’t find that in the process industries. If I go into a power plant or I go into a refinery, there’s not a lot of duplication inside the facility. There might be between two different facilities, but there’s not a lot inside a facility. Where in pipelining and in midstream, there’s a lot of replication.

You still have to review everything. It’s not copy, paste, forget. It’s copy, paste, review, and analyze. Even so, having a baseline understanding of how it needs to be modified is a much different thing than starting from scratch every time.

Stephen:  Especially if that team has the opportunity to be consistent throughout the process, where that team doesn’t have to start out by meshing at the beginning. If it’s the same group of folks that can review and then all immediately be on the same page from last time and not have to start over, review, recollect, and go.

Russel:  Oh man! You are saying a mouthful.

I think this is one of the reasons that some of these small midstream companies are so successful is they get a small team of engineers that work very well together across multiple disciplines. They’re able to share experience. Their rate of learning and their ability to get that learning into the next thing they do is very accelerated. There’s a lot of value in that our business, a lot!

Stephen:  There is. That’s one of the principles of a mature process safety program is process knowledge preservation. Unfortunately, from my perspective in previous lives, previous experience, that’s limited to SOPs generally. But it can be much bigger.

Russel:  It’s such an easy thing to say and such a hard thing to do. Because the kind of thing we’re talking about cuts across a whole lot of disciplines, it’s a very difficult thing to implement.

Stephen:  Our industry, as much as people move around and change roles to diversify experience, which is great, there’s a lot of legacy planning conversations that happen around who’s going to fill what role. But there’s not a lot of legacy “hand down your process knowledge to the right backfill” conversation that goes along with that.

Russel:  Even if there is a lot of that knowledge, they may not have the depth.

Stephen:  That’s exactly right.

Russel:  It’s one thing to know how measurement works. It’s another thing to understand it all the way from the instruments through the accounting system. It’s one thing to know how the process works. It’s another thing to understand it from the foundation and the concrete and the site plan all the way through, again, how it’s achieving a commercial objective.

Stephen:  Very true.

Russel:  I think we’re at a good place to wrap up. We’re waxing philosophic here. A lot of these episodes, I try to take it down to three key takeaways. I’m going to try that again. You can give me a letter grade on how well I do.

I would say the first key takeaway here is that there’s big opportunity and possibility if you can take and do alarm management and process safety management as an integrated process.

I think the other takeaway is that, while the conversation is very similar, the outcomes you’re working towards are very different. Process safety management, I’m trying to make a system mechanically safe. Alarm management, I’m trying to be able to operate it without hitting my process safety shutdowns.

Then, lastly, I think there’s some pretty big cultural and just the reality of our business challenges to doing that. Boy, if there’s somebody out there that’s trying to do this, [laughs] I sure would like to hear from them. I’d very much like to compare notes.

Stephen:  Absolutely.

Russel:  Four takeaways, thought I had three. [laughs] What do you think?

Stephen:  Solid A on that assessment.

Russel:  [laughs]

Stephen:  That boils it down for sure.

Russel:  Stephen, thank you so much for coming on and talking about things. This was very educational for me and hopefully for the listeners as well. If somebody wanted to get in touch with you and talk about PSM and the process and compare notes, how might they get in touch with you?

Stephen:  The best way to get in touch with me would probably be my email. That would be skswanson37@gmail.com.

Russel:  Of course, we’ll link that up on the show notes. Stephen, thanks again. We’ll look forward to having you back once you and I both have an opportunity to try and walk a ways down this thing we’re imagining as a possibility.

Stephen:  Absolutely. I’m excited. Thanks for having me.

Russel:  Hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Stephen Swanson.

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 the podcast, please leave us a review on iTunes,/Apple Podcast, Google Play, or wherever you listen to podcast. You can find instructions at pipelinepodcastnetwork.com.

[background music]

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

Transcription by CastingWords