The latest episode (S1E30) of the Kenexis Functional Safety Podcast is now available on Spotify and Apple Podcasts

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E30 TRANSCRIPT (Markdown)
Cleaned & reflowed for web publication and AI crawlability.

The JSON-LD block below is schema.org structured data. If your CMS lets you
add raw HTML to a post, paste it into the page (or anywhere in the
body — crawlers read it either way). Fill in PLACEHOLDER_EPISODE_PAGE_URL
once the post exists. Everything from the "# Kenexis Functional Safety
Podcast…" heading down is the transcript body — paste it into your post.
–>

"`html

"`

# Kenexis Functional Safety Podcast — Season 1, Episode 30: IEC 61511, Clause 11.1 to 11.2.5 (SIS Design and Engineering)

—

## Episode Teaser: Clause 11 Preview

Finally, we get to my favorite part of the standard, Clause 11, where all the action happens.

## Introduction and Course Overview

Welcome to the Kenexis Functional Safety Podcast. I'm your host, Ed Marszal, President and CEO of Kenexis. Kenexis is a technical safety consultancy that helps chemical process industry companies to analyze risk and design engineered safeguards like safety instrumented systems and fire and gas detection systems. Kenexis also provides the industry-leading suite of software tools, including our best-in-class Vertigo software for SIS safety lifecycle management.

In this first season of the podcast, we are going to focus on the IEC 61511 standard, doing a deep dive into the standard, including more depth of information on what the standard means and how to apply it, brought to life with personal war stories and behind-the-scenes discussions of the committee members as we develop the standard in ISA 84 and IEC SC 65.

Before we start, a little disclaimer. I will be providing my opinion on technical and engineering topics. This information is provided on a best-effort basis and is of a general nature. The information presented in this podcast might not be applicable to your specific application. It is the obligation of every engineer to thoroughly analyze any system that they are designing and not blindly rely on any general advice presented in this podcast.

## Clause 11 Scope and Purpose

So at long last, at long last, we have made our way to Clause 11 of the Standard, which is the title to the Clause of the Standard is going to be SIS Design and Engineering. And what the purpose of this clause is, is to put prescriptive requirements into a performance-based standard.

That's right.

You heard me correctly. I have been preaching from the get-go about how this standard is performance-based, how you pick a target and then verify that you've achieved that target. And that's what your design is, which is intended. That type of performance basis is intended to give you the ultimate flexibility to decide what equipment you're going to use, how you're going to test it, how you're going to configure it, and so on.

But at the end of the day, the Standards Committee is still going to put some prescriptive requirements on you because, well, you know, can we really trust you to design these things yourselves? Yes, but, you know, hey, I can't speak for the entire committee. I believe you guys are the best. I mean, you'll figure it out. You know how to do it. You know what you're doing. But, you know, those other guys, they just don't trust you.

But there's actually a lot of good information in here. The tools and the techniques that we're talking about here for designing the safety instrumented system, they just make a lot of sense. And they cover a wide range of topics that are kind of detailed design based.

So without further ado, let's dip our toes into Clause 11. And we're going to be spending a lot of time here in Clause 11 because there's a lot to be done here. There's a lot of. — each clause is going to have just an absolute ton of discussion behind it.

This is where the most stories reside. This is where the most best practices and variety of design options for how you're going to build this system out. It's all here. So we could take a good bit of time going through Clause 11. And honestly, we really should. Because, honestly, this is where all the good stuff is. Let's be serious.

Okay.

So getting back into it, Clause 11 is entitled SIS Design and Engineering. So we just finished the safety requirement specifications. Well, in reality, we just read the clause that contains the SRS requirements. We're not actually going to be done with that SRS until right before startup. We're going to continue to make changes to it. But we did our hazard and risk analysis. We designed our safety instrumented system in terms of the safety requirement specifications. Now we're actually going to do the design and the engineering. And Clause 11 is focused really on hardware design.

Now, I'm going to talk about it in terms of an overall design perspective. But Clause 12 is going to talk about the design of software specifically. So what's in Clause 11 basically realistically would also cover the design of low variability language software. But there's some additional stuff in 12. We'll get to 12 when we get to 12. Right now, we're still in Clause 11. So SIS Design and Engineering with a Focus on the Hardware Design.

## Clause 11.1: SIS Objective and Integrity Targets

We begin with Clause 11.1, which in the new format of the IEC standards contains the objective. What are we trying to achieve in this clause? And that is the objective of the requirements of Clause 11 is to design one or multiple SIS to provide the SIF and meet the specified integrity requirements. For instance, safety integrity level, SIL, associated risk reduction, if you define a risk reduction factor, PFD, probability of failure on demand, and or the PFH, probability of failure per hour, aka failure rate, if you're in the high demand or continuous demand mode of operation.

Okay, so what do we got here? The objective is to design one or multiple SIS. So you might be designing one SIS. You might be designing multiple SIS. And those SIS or SIS is supposed to provide SIFs. So the SIS contains many safety instrumented functions, or it should. But I mean, each SIS is going to have a minimum of one safety instrumented function. And the safety instrumented function or functions are going to be required to meet the specified integrity requirements, which we just got done picking back in Clause 8 and Clause 9 and writing down in Clause 10.

So we have a list of our safety instrumented functions that we're trying to achieve their performance targets. And during Clause 11, we're actually going to do that. Okay.

I don't know how helpful that objective is. Yeah, go design it. Go design the SIS that you just wrote down what it's supposed to do. Okay, let's continue moving on.

## Clause 11.2.1: Design Conformance with SRS

And once we get to Clause 11.2 or .2 of any clause, we start actually putting down the normative requirements, the things that you're required to do. So let's start with Clause 11.2.1. Clause 11.2.1 says, The design of the SIS shall be in accordance with the SIS safety requirements specifications, taking into account all of the requirements in Clause 11.

So, all right. In this clause, we're kind of limiting what you can do in terms of when you're doing your design, it needs to be in accordance with your SRS. So you wrote a design documentation.

Now you need to build to that design, which this might come as a shock to a lot of people who supply SIS lifecycle management software or those people that are, you know, a little bit more certification and audit oriented that, hey, you know, that SRS that we wrote, that should be the basis for how you design the system, not some sort of auditor's checklist after the fact or a piece of document that will, you know, allow a third party certification agency to put their gold star sticker and say, hey, you guys did good. So we're going to design our system in accordance with the SRS.

What does that mean?

Well, at a minimum, we need to have enough of the SRS done so that we can do the design. Okay. That's important. You're probably not going to have it all done. Oftentimes you're not going to have it all done until real close to end right before you start up. But enough of it done to do your design. What else does this mean?

If you are making changes, if you're adding functionality, you shouldn't just be adding functionality during the design process. If that functionality is not included in or conflicts with the SRS. Why is that important? Well, if you're going to make changes to the safety requirement specifications and the safety requirement specifications need to be the basis for your SIS design, then if you, during the design process, realize that the safety system needs to do something you didn't think of while you're doing the SRS, well, you need to return to that phase first.

So you need to go and update the SRS instead of just writing the code in. So when you're done with all of the design process, the design should match the SRS.

It's not like you're going to, you know, do the design and then, okay, well, maybe before startup, I'll go back and fix the SRS to match what I actually did. That's really kind of unacceptable. You're asking for trouble. You're asking for problems.

If you're in the middle of the design process and you notice something is wrong, you notice something needs to be added, something needs to be changed, you need to pause the design process, go back to the SRS process, rewrite the specifications, go through the verification process, go through the approval process for the safety requirements specifications before you come back in here and start doing the design.

So it seems like a kind of a throwaway clause. Yeah, of course. Duh. No kidding. My design needs to be in conformance with our SRS. But it's shocking how many people kind of ignore that. They think they know what the system's supposed to do and they ignore the documentation. SIS design is a team sport that's including auditing and verification and validation, functional safety assessment. We need to keep all that document up to date and consistent among all the steps in the SIS safety lifecycle.

## Clause 11.2.2: SIF and Non-SIF Separation

Okay, clause 11.2.2 is the very beginning, and there's going to be a lot of these clauses that we're going to get into that talk about separation. And by that, I mean specifically when you're designing the safety instrumented system, you want to make sure that it is fully and functionally independent of all protection layers need to be physically and functionally independent of each other. So specifically for the safety instrumented system, physically and functionally separated from the basic process control system.

Now, the first clause is a little bit weird because it starts with where the SIS, SIS is to implement both SIFs and non-SIFs, then all the hardware, embedded software, and application program that can negatively affect the SIF under normal and fault conditions shall be treated as part of the SIS and comply with the requirements for the highest SIL of any of the SIFs it can impact. Okay, so before we even tell you to separate the SIS from the basic process control system, in clause 11.2.2, we're already saying, yeah, your safety instrumented system is going to be running stuff that's not SIFs.

So, what are some of the most common things that you're going to see that are wired into the safety instrumented system that are not SIFs or not part of SIFs? Let's say I have a fired heater or just any shutdown where I measure a process variable like fuel gas pressure. And when that fuel gas pressure is abnormal, I am going to close a valve to get myself to a safe state. Okay, that's the safety function. Measure pressure, decide if pressure's abnormal, if pressure's abnormal, close a valve.

Well, I might also wire up some limit switches or a positioner on that valve and put some logic in or alarms that will do a comparison between where did I command that valve to be and where exactly is it right now? So, the command versus measured position mismatch. So, I commanded my valve to go open, but it's not open. The open limit switch didn't make. So, now I've got a mismatch and that's going to generate an alarm to, you know, at a minimum, have the operations team investigate what happened. Did the valve actually close and the limit switches were broken?

Did the valve not actually close? Do I need to take some sort of other manual action to isolate that stream that the valve was on that I was trying to close in order to get to a safe state?

That functionality, the limit switch, the communication to an alarm system, the generation of alarm, it's very common to wire, to land those wires in the safety instrumented system hardware. It's very common to do the logic to generate the mismatch alarm in the SIS logic solver. But that functionality is not part of a SIF. So, what you need to do in your design is number one, you're going to try to design all that so it's separated to the greatest degree possible. So, you're going to land your wires away from each other to create physical separation.

You might want to run your logic on different pages so that the comparison and the alarming is on one page of logic, whereas the actual safety instrumented function is on a different page of logic to try to separate them to the greatest degree possible.

And you want to, and I'm going to coin a phrase here for you, well, I'm not going to coin the phrase, I'm going to use the phrase that's been coined, you want to make that functionality non-interfering with the safety instrumented function. So that any failure of that non-SIF hardware, non-SIF software, is not going to cause a failure of the SIF. Okay? That's what we're striving to do.

Now, all the hardware, so if it's non-interfering, that's our goal, that's what we want to do. But there are some situations where some of this non-SIF-related hardware can negatively impact the safety instrumented function. So if the code can't be separated or the hardware can't be separated to where, you know, failure of this non-SIF functionality will actually cause a failure of your SIF.

If that's the case, then you need to treat that non-SIF hardware as though it were part of the safety instrumented system, system, and it needs to comply with the SIL requirements of the highest SIL of any of the safety instrumented functions that it can impact. So if a failure of a piece of hardware that you have wired in for non-SIF functionality can impact the SIL-2 SIF, you need to treat that hardware as though it were part of a SIL-2 system for design and testing and every other reasonable purpose of the design.

So, you know, we talk a good game, we talk a great game about separation of basic process control and safety. And what you're going to see as we go through the standard more and more, there are all kinds of exceptions, all kinds of exclusions where we say, well, yeah, but, yeah, but, and you know, the, the exclusion here is, yeah, you might be putting some hardware into your SIS that's not part of the SIF, and that's okay. It's really okay if it's non-interfering, but it's even okay if it is interfering, if it can negatively affect the SIF.

But when you do that, you need to treat it like part of the safety instrumented system, account for it in the design, account for it in your PFD calculations and so on. All right, that was clause 11.2.2. Let's move on and talk about the next clause, clause 11.2.3, which has an informative note.

## Clause 11.2.3: Mixed SIL Levels in Shared Hardware

So I'll get to both of these items. So starting off one sentence clause 11.2.3, where the SIS is to implement SIF of different SIL, then the shared or common hardware and embedded software and application program shall conform to the highest SIL. Okay, we're at a fired heater, were we not? Or I just talked about one a second ago.

This is a very common application because in a fired heater, whether it's high fuel gas pressure or low fuel gas pressure or low air flow or high combustibles concentration in the stack, any safety instrumented function in that fired heater is generally going to close the fuel gas valves. Because once you close the fuel gas valves, you're going to get to a safe state, regardless of the multiple different ways that you could get yourself into trouble. So the shutoff valve on the fuel gas is part of multiple different safety instrumented functions.

So the high fuel gas trip pressure trip might be SIL 2, the low fuel gas pressure trip might be SIL 1, the low air flow trip might be SIL 3. So the shutoff valve or the shutoff valve subsystem is going to be part of a SIL 1 function, a SIL 3 function, and a SIL 2 function. Well, when that happens, the shared or common hardware needs to conform to the highest SIL. So it needs to achieve that SIL 3 if SIL 3 is one of the functions that's part of the loop. And that's going to have hardware ramifications for things like hardware fault tolerance.

It's also going to have ramifications for embedded software. So the software that's running on your PLC, for instance, or on your transmitters even have embedded software, and even the application software that you write, you will need to conform with the highest SIL requirements.

When we get to clause 12, we'll talk about how, well, definitely in IEC 61508, different SIL levels mean different things about how you write the software. That's not really that much of the case when you're doing limited variability languages in accordance with IEC 61511. But we'll get there. That's all in clause 12.

Now, there is a note to this clause 11.2.3, which says, Note, embedded software or application programs of different SIL could coexist in the same device provided it can be demonstrated that the SIF of lower SIL SIL cannot negatively affect the SIF of a higher SIL. Okay, what's that telling me? I've got a SIL 1, SIL 2, and a SIL 3 safety function in my logic solver, which is exactly the case that I was just talking about. That's okay.

It's okay to have a SIL 1 safety function in the same SIS, the same logic solver, as a SIL 3 safety function, as long as a failure of the SIL 1 safety function can't negatively impact the SIL 3 safety function.

I don't know. A lot of this sounds… I don't even know why we're talking about this. It just seems so utterly obvious that it doesn't need to be said. But darn it, it's been said. So there we go. It's a requirement. And it's just kind of like, yeah, good to know. That's how I designed my system. We're good. Thank you.

## Clause 11.2.4: BPCS and SIS Independence

All right, moving on. We're going to get to clause 11.2.5. And 11… I'm sorry, 11.2.4. And 11.2.4… Hmm. We're doing a lot of commonality and sharing. So in 11.2.2, we talked about SIF functionality and non-SIF functionality in the same SIS. 11.2.3, it was pure SIS stuff, but different functions of different SIL levels. Now, in clause 11.2.4, this is the first time we're going to throw down and try to put that prescriptive requirement on your design of the SIS for separation.

So it starts out with the first parenthetical statement of 11.2.4 is, if it is intended not to qualify the BPCS to the IEC 61511 series. Okay. You're going to see that clause show up many, many, many more times before we're done. So what we're saying is if your basic process control system is not the SIS. Now, why you would want the basic process control system to be your SIS boggles and befuddles me. There's virtually never any reason to use a combined system that is an SIS and a BPCS, but it has been done.

Some people have done it, and you just need to basically do everything that you do in your basic process control system. You need to treat it like it were an SIS, which generally makes your plant unrunnable because you're going to need to run management of change approval and paperwork every time you change a set point.

So, basically, bottom line here is we're talking about the safety instrumented system and the basic process control system being different boxes. They're separate from each other, and we're not going to design the basic process control system to achieve any SIS to meet any of the IEC 61511 requirements. So we're taking all of the IEC 61511 requirements off of the basic process control system. So that's the plan. We're going to have a BPCS that is not the SIS. We're not designing it in accordance with IEC 61511, comma.

Then the SIS shall be designed to be separate and independent from the basic process control system, period.

*[inaudible]*

Nope. There's no period there. So we're going to design to be separate and independent from the BPCS to the extent that the safety integrity of the SIS is not compromised. So our first throwdown that says you need your BPCS and your SIS to be completely physically and functionally separated, we're already backpedaling and saying, yeah, actually you can do some combination. But when you combine the BPCS and the SIS functionality, and that includes field devices, not just the logic solver, you may be able to do that.

But you want to keep them separate and independent at least to the extent that the safety integrity of the SIS is not compromised.

So if you're going to do some kind of sharing, whatever that sharing is, whatever that sharing looks like, it cannot compromise the safety instrumented system's ability to achieve its functionality at the desired SIL target. So there's a PFD kind of metric that's going to get thrown on there. We're going to come back to this. Let me tell you, we are just ever so slightly, ever so barely touching the concept of separation. It is going to continue to get watered down as we move through this standard. Okay.

There are two notes to clause 11.2.4. They are, number one, note one, operating information can be exchanged, but not compromise the functional safety of the SIS.

Aha. So right in note one, we're immediately acknowledging, hey, the BPCS and the SIS are probably going to be talking to each other. That talking to each other is going to include operating information. Now, when we get to clause 11.13, we're going to spend a lot of time talking about interfaces between the basic process control system and the SIS. So I'm not going to belabor the connection between the BPCS and the SIS right now in terms of information exchange.

But most of the time, you're writing from your SIS to the basic process control system information that the operator is going to want to see.

But there are two items, and I'll give you a little bit of a preview. There are two items that you routinely communicate from the SIS to the basic process control system. Those items are bypasses, number one, and resets, number two. So it's those two items of information that are routinely going to get passed from the basic process control system to the SIS. And we're going to need to do quite a bit of work to make sure that we can do that safely.

And when we get to clause 11.13, I'm going to explain a lot of the different ways from hardwired switches, bypass-enabled dead man switches, digital ping-pong. But that's weeks from now before we get there. That's all the way out in clause 11.13. So, yeah, when you exchange data, you need to make sure that you can't compromise the functional safety of the SIS. So you want to make sure that you don't accidentally put something in bypass, because that's a dangerous failure of the SIS. I'll show you the methods, but not quite yet.

We're going to get there.

Note number two to clause 11.2.4 says, Devices of the safety instrumented system can also be used for functions of the BPCS, if it can be demonstrated that a failure of the BPCS does not compromise the SIF of the SIS.

So, my goodness, I mean, the note here basically says, if I've got a transmitter, if I've got a logic block, if I've got an output that the safety instrumented system is using, well, the basic process control system is allowed to use it too. But if and only if that failure of that shared component cannot compromise, or failure of the basic process control system through use of that shared component will not be able to compromise the SIF of the SIS. Okay, there's a lot of ambiguous, sketchy information here.

Don't share, but, you know, you can share as long as you're not compromising the SIS's ability to do its job, as long as, you know, these failures aren't going to impact the SIS's ability to do what it does.

So, kind of coming out of clause 11.2.4, there's this concept that if I'm kind of commingling basic process control and SIS functionality, that's going to be okay as long as there's no failure that happens in the BPCS that's going to cause a safety instrumented function to fail dangerously. That's the gist of clause 11.2.4. But as I mentioned, we're just getting started here on this topic, and the rubber isn't really going to meet the road until we get into clause 11.2.10, where we throw down and say, you know what?

If you want to do this sharing, you better prove it numerically using fault trees. More on that coming up probably not even next week. It's probably a couple weeks from now because there's so much to talk about. That's going to be in clause 11.2.10. We just finished up clause 11.2.4.

## Clause 11.2.5: Operability, Maintainability, and Testability

So let's do, you have graced me with your attention for quite a while now. Let's go ahead and throw down one more clause for this episode, and that's going to be clause 11.2.5. All right. So this clause talks about requirements. Okay. Did we already specify what all the requirements were back in clause 10, the safety requirement specifications? Well, apparently it's telling me here in clause 11.2.5 that I need to define some more requirements after I already defined what my requirements are.

So again, one more reason not to get dogmatic on the order of things in the flow chart. All right. Specifically, when we're looking at clause 11.2.5, we're getting a little bit away from the realm of the theoretical and into the realm of the real and the practical. So specifically what we're talking about, let's just go ahead and read it out.

Clause 11.2.5, the requirements for operability, maintainability, diagnostics, inspection, and testability shall be addressed during the design of the SIS in order to reduce the likelihood of dangerous failures. Oh my goodness, do I have war stories here.

Because this, it's a clause. It's saying you need to think about how you're going to maintain and operate this equipment while the plant is online and running. But so many designers ignore that. And so many of these highfalutin, overpriced consulting companies, they ignore it too. You know, a lot of times there's some equipment vendors who shall remain nameless, who want you to buy their stuff and spec it out during the design process, only to realize, yeah, I can't actually implement that. And I'm one week before startup, so I'm in big heap trouble.

So what do we mean for requirements for operability, maintainability, diagnostics, inspection, and testability? Okay, testability, the last one.

I have a consultant. I have seen reports from consultants where, and again, you know, I'm coming in after the fact. You know, please, Ed, come to our site and give us a lecture and answer some questions for us. And the first question is, okay, we got this report from consultant XYZ, and in their SIL verification calculations, they said that we're going to do a full stroke test of this valve every six months.

And, you know, logic solver once a year, sensors, you know, once a year. But we're an oil refinery, and this plant doesn't shut down but once every four years. I don't actually have to do what they said in their calculations. I'm like, yeah, you kind of do. Or that's what the expectation is, you know, in order to achieve tolerable risk.

Now, the good news for this company is that the consultants that they paid a ridiculous amount of money for were so incompetent that they put in a six-month test interval on these valves, but they could easily have achieved a four-year test interval because they had double block valves.

So, I don't know what they were thinking. So, in that case, they were lucky because all we had to do was rerun the SIL verification calculations and generate a new report. But bottom line here is if you say something's going to be tested once every six months, you have to make sure that that's physically possible. And how is the test going to be performed? So, if you're going to do a test, a full-stroke test online, you need to make sure the equipment's there. You need a full-diameter bypass around that shut-off valve that you're going to be able to use to make the test happen.

Okay, so the ability to do inspections, diagnostics, after the plant is up and running is not the time to start putting the diagnostics in. And also, diagnostics, this is another huge pet peeve of mine. A lot of people will take credit for diagnostics because the software that's out there makes it really easy to do it. And some of the people that have software who also partake in doing a lot of certifications, you know, they basically, you know, the diagnostics that are parts of transmitters are part and parcel of the system.

You know, it's inconceivable that you wouldn't consider the diagnostics in your calculations. Well, if you're going to consider the diagnostics in your calculations, you need to do something about it. And I have many, many times gone and seen a system, a completed system installed where they took credit for diagnostics in their SIL verification calculations. But the safety instrumented system, the logic solver, it's capable of knowing that, hey, the transmitter is sending me a unacceptable signal because at the logic solver, it's a bad PV.

I know you can't see me doing my air quotes, but it's a bad PV. And what did they program the system to do when a bad PV comes in? Nothing. Just keep operating with a bad PV. Okay. In that case, you didn't write down requirements. You didn't program your PLC to appropriately respond to those diagnostics that your sensors are generating. And your SIL verification calculations in that case need to be redone to remove the diagnostics because you're not using them. Okay.

Calculations, design, consistency. It all needs to be there. Operability, maintainability. Now, on the maintainability side, and I'm kind of going, you know, giving you a horror story, war story for each one of these items.

Maintainability.

This is great. And I'm going to give another big shout out to my long time buddy, formerly of the Sunoco Refinery in Philadelphia, Mr. Ron Plimers. Shout out. Hopefully you're listening to this, although you're retired, so there's no reason for you to be listening to this anymore. But Ron Plimers invented something called the Plimers Manifold, which I'll discuss in just a second here.

But in terms of maintainability, let's say you do a partial stroke test on a valve. I'm in an oil refinery or a petrochemical plant that only shuts down once every three, four, five, six years for a turnaround. Now, I say I'm going to use a single shutoff valve because if I do partial stroke testing, I'm still going to be able to get to my SIL2 target for five years, what have you. Okay, let's say you could do that. If your partial stroke test shows that your valve has failed, what do you do?

Ooh, sticky. You need to repair that device within 72 hours. What was your assumption in your SIL verification calculation? That's how much time you have to go fix it. Well, how do I fix this valve? Because I can't take the valve out. The process is running. Okay, so a lot of people will design their SIS shutoff valves with no bypass around it. No way to repair the device. Because, well, you know, bypasses get abused and I don't want people putting stuff in bypass and disabling my safety system. Well, guess what? You can't do any repairs either. Sure.

So, so, Ron Plimers invented the Plimers manifold. So, envision this. You've got two parallel pathways and one of the pathways contains your shutoff valve. And the other parallel, it contains the shutoff valves, the flanges and isolation valves upstream and downstream of the shutoff valve. Now, there's a parallel pathway right next to it that contains inlet and outlet isolation valves and flanges but there's no valve in it.

There's just blind flanges. What is the benefit of this Plimers manifold? Well, if your primary shutoff valve fails, what you can do is you can go to the shop, get your spare shutoff valve, go out to the field, take the blind flanges off, insert the spare new valve, get it all lined up, tightened up, ready to go, then put your SIS in bypass, remove the top works of the valve that's in service and put it on the spare valve. And guess what? Now your spare valve is your primary active valve.

Open up the valves, inlet and outlet isolation valves after, of course, closing the, obviously, you close the inlet and outlet valves on the other valve after you open, you know, your bypass route and that's going to allow you to take the valve that failed out, back out to the shop and service it. And all of this can happen without actually having to install a full bypass.

Now, as we extend our test intervals and we want to start doing full stroke tests while the plan is online and running, we're probably going to forego the climber's manifold as elegant as it is and just have a full diameter bypass because, well, that's what it's going to take to be able to do that full stroke test instead of just the partial stroke test.

Okay, so that's maintainability. Now, the last item, man, I've been on this clause for a while. I've been doing this for 30 years, man. I got war stories. I got horror stories. The last one is operability.

So, can I operate and, you know, can the operators make the safety instrumented system do what it's supposed to do? So, the first, you know, item of this is the shutdown that works so well that it doesn't allow you to start up. If I have a low flow shutdown on a discharge of a pump, how pray tell do I start the pump? The shutdown system is preventing you from pulling in the motor starter but until I pull in the motor starter, I can't start the pump and get a flow going. So, you need to have auto bypass, auto rearm, which I will come back to several more times.

I'm not going to talk about it in detail now. We're getting toward the end.

Um, and, but also, um, you might just have a hard-wired bypass. There are a lot of different bypass options. We're going to talk bypass to death. Don't you worry. We're going to come back to it again and again. Uh, but those are some of the things that you need to think about.

Can I actually operate it? And the last horror story is, do you have the stroke to make your operations team actually use your design? So, I will give you the horror story of an oil refinery that spent hundreds of thousands, maybe millions, definitely hundreds of thousands of dollars on super fancy, high-sil rated partial stroke testing equipment.

This partial stroke testing equipment had all kinds of redundancy, all kinds of diagnostics, uh, that will, you know, if you don't know what a partial stroke test is, I will keep mentioning it over and over, but for a shut-off valve, for instance, you'll, instead of closing the valve all the way, you'll close it a little bit to make sure it moves and then open it back up. Well, the engineering team at this refinery was working with a consultant who had all kinds of excitement for using these partial stroke tests. They may or may not have made money from licensing the design of this equipment.

So, even with consultants, not just, uh, the, uh, equipment vendors, you have to be very careful about conflicts of interest because they're going to spec out their stuff, whether it's good for you or not. So, be careful. Caveat mTOR, buyer beware. Now, um, so they spec'd out all of this partial stroke testing equipment.

Now, when I got to site, they're like, I have, we have a problem because we didn't install any of the partial stroke testing equipment. And I'm like, okay, um, why? You know, first question, why? And it's very common. Uh, if you haven't run into this, you're going to run into this if you're a designer and not the operator of the plant. What you're going to do is you're going to go into the control room and, you know, right at the beginning of a turnaround, you're going to be talking about the new SIS, maybe doing some training on the new safety instrumented system.

And you're going to say to the operators, we have implemented some automatic partial stroke testing. And the operator's ears are going to perk up and they're going to say, what now? Uh, what exactly is it that you think you're going to do? Oh, oh, this is great. It's state-of-the-art. All the high-priced consultants are highly recommending doing this. And what we're going to do is we're going to automatically have the control system start moving the valve to the closed position a little bit, make sure that it moves and then open it right back up again.

And the operator's then going to say, excuse me, what did you say you think that you're going to do? Um, we're going to close the valve a little bit and open it back up. Oh, hell no. Hell no. No, you're not. You're not, you're not moving that valve. Your automatic system is not going to do some kind of fancy test where we're going to move the shut-off valve a little bit and hope that it doesn't close all the way and bump my process and cause all my flows and measurements to go crazy in the process. No, no, no, hell no, you're not doing that.

So, and unfortunately, they had piles of this stuff sitting on their dock. And they're like, well, what do we do now? I'm like, well, did you take credit for the partial stroke testing and your SIL verification calculations? And they're like, I don't know, the consultant did it. I guess maybe another one of the big lessons learned here is you people at the operating companies need to learn these calculations yourself. They're really not hard to do, especially if you're using really good, user-friendly, easy-to-use software like Vertigo from Kenexis.

business. But alas, we took the calculations from that third-party consultant and we re-ran them and it turns out that it was completely unnecessary to do the partial stroke testing to meet the SIL target. So basically, the downside is they just paid a boatload of money for a bunch of equipment that they never ended up using. And as far as I know, somewhere south of Columbus, Ohio, I won't say where, all of those partial stroke testing apparati are sitting on a loading dock somewhere taking up space.

Maybe they were able to, you know, sell them on eBay or something but they definitely never ended up using them because operations said, no, you're not going to do it.

Okay, so that's Clause 11.2.5 and that is all the further I'm going to go today. Next week, maybe we're going to get to Clause 11.2.10 so a little bit more on that separation. But we're going to start out talking about human capabilities. And it's going to be one of my first forays into why we don't ever calculate the probability of failure of a human as part of a SIL verification calculation. But all that is coming up next week. And have a good week until then. Looking forward to talking to you again soon.

## Kenexis Vertigo Software Overview

Now that you've heard some insights on technical safety, functional safety and the IEC 61511 standard, let me tell you a little bit more about how to easily and effectively implement the safety life cycle using the Kenexis integrated safety suite and our SIS safety life cycle management tool Vertigo.

Vertigo is a comprehensive tool set for performing assessment calculations, documenting and maintaining the design of safety instrumented systems.

Analysis begins with importing or synchronizing a list of safety instrumented functions with their definitions and associated performance targets from our open PHA tool for HAZOP and LOPA documentation.

Each safety function can then be analyzed by performing a SIL verification calculation.

Complete with a collection of tools for optimizing designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities.

After the SIL verification calculations are defined, you can build an SRS by automatically generating a cause and effect diagram from the SIF definitions and other defined instruments.

Each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries.

After the design phase, you can even use Vertigo to track and document testing throughout the entire life of the facility.

Kenexis Vertigo is the most integrated, easy to use enterprise tool for allowing the development of SIS design basis information more efficiently and effectively than any other software application.

> *

*

## Episode Sign-Off

Thank you.