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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E32 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 32: IEC 61511, Clause 11.2.8 (Manual Means of Shutdown)

—

## Cold Open and Episode Introduction

Do you actually need a manual shutdown switch? And do you need that switch to be independent of the logic solver? Vic Majoli thinks so!

> *[Intro music, 00:30 – 01:30]*

That is those shutdown buttons. So more buttons. Last week we were talking about the buttons that allowed you to reset, bringing your process back to normal operating condition from a shutdown state. And this week we are actually going to talk about the shutdown state itself. Creating the shutdown state with the emergency stop button.

All of this is in clause 11.2.8, which is one sentence. But this one sentence is so loaded, so controversial, has so many fingers going in so many different directions that we're going to dedicate the whole podcast to this one sentence in the standard.

## Origin of the SCRAM Acronym

So, all right, kind of big picture. Emergency shutdown buttons.

There are a lot of standards that require the operator to have some sort of button that they could push to manually bring the process to a safe state. The emergency shutdown button is a time-honored tradition going back hundreds of years, predating computer systems, predating electrical systems. The most early automation had ways that a human operator could somehow push a button, flip a switch, maybe even use an axe to cut a piece of rope.

So, today is going to be full of all kinds of good stories. So, the first story is of the rumors, probably more apocryphal than true, about the origin of the word scram that's used in nuclear power generation. So, when you are generating electricity using a nuclear reaction in the most old-school, traditional way, especially kind of in the Manhattan Project era, the reaction, the sustained chain reaction that is splitting atoms can go out of control. If it goes out of control, very high temperatures can rise, very bad things can happen.

You know, that's why they have bombs that are built out of the same, well, not exactly the same fuel. I'm getting a little bit off topic here. But, there needed to be a mechanism by which if this reaction, if this chain reaction went out of control, we want the operator to be able to shut things down, to be able to get the process into a safe state. And, the name for the manual means of bringing this nuclear reactor into its normal operating state was called the scram. And, there are all kinds. So, go ahead and, you know, search the internet.

Do an AI search for the origins of the word scram in relation to nuclear power or safing nuclear power.

But, one of the fun stories, again, probably more apocryphal than true, is that the scram is related to an axe. So, here's the theory. Here's the story. If the chain reaction went out of control, then there was an operator, a specific person, who would be able to get the reaction back under control by inserting graphite rods into the reactor. So, we're going to drop the control rods into the reactor.

And, the purpose of these graphite rods is going to be to absorb the neutrons so that, you know, once the neutrons get absorbed by the graphite, they're not available to cause another fission of another atom. And, that will slow down and or stop that chain reaction that is generating all of the heat and generating all of the power.

Now, what was the earliest mechanism to insert these control rods into the reactor? Well, this is where things are kind of not necessarily known. But, you know, based on all my experience working with some of the legacies that are the result of the race to nuclear power, the Manhattan Project, what happened at Oak Ridge, what happened at the Hanford site, I am willing to go out on a limb and say that people were doing things kind of jury-rigged, kind of, I don't want to say half-baked, but they were using some rough and ready methodologies to make things happen.

And, you're probably not going to be surprised to hear this, especially if you're in the safety industry, which I assume you are, since you're listening to this podcast. Yeah, safety tended to get a backseat everywhere.

So, all right, so back to the story here. The maybe true, maybe not, good story. Nonetheless, was that the mechanism for safety in the first chain reactors, chain nuclear reactors, was gravity-fed. So, what we're going to do is we're going to take these graphite control rods, and we want to be able to put them into the path of the neutrons when we want to, but we want to have them out of the way to allow our chain reaction to occur if that's not the case. So, you know, one of the cheapest, quickest, easiest things that is available is gravity.

So, why don't we kind of mount the control rods above the reactor, and then if the situation goes out of the control, we'll just drop the control rods into the reactor. Well, how are we going to do this? Well, why don't we just take the control rods, the mechanism containing the control rods, and we'll just kind of put a hook on it, and we'll get a piece of rope, and we'll kind of have it hanging from the ceiling. And then all we have to do is when things get out of control, we're going to cut the rope. Well, how are we going to cut the rope?

Well, obviously, we'll just kind of have an axe there. So, we'll put the rope kind of by a block of wood, and then when we want to drop the control rods in, we will just use our axe to cut the rope, which is going to drop the control rods into the reactor.

So, this initial archaic, jury-rigged, rough-and-ready safety instrumented system, or manual means of shutdown, then, the story goes that it was called the SCRAM, or the Safety Control Rod Axeman. So, SCRAM, one story, apocryphal or true, is that SCRAM means, it's the acronym for Safety Control Rod Axeman, and that's the person who's going to run out with an axe when the reactor's going out of control, and chop that rope and drop the control rods into the reactor to bring it back to a safe state.

Not exactly a job that I am going to volunteer for, and, you know, that's actually part of the thinking, part of the process. When you're going to design a manual means of shutdown, is do you actually physically expect someone to be able to go out and flip the switch, or in this case, take the axe to the rope? We actually talked about that last episode in Clause 11.2.6, where we said the design of the SIS shall take into account human capabilities and limitations, and one of those limitations might be, yeah, I'm not going out there.

So, all right, enough of that. That's just my first good story of the day, the origin of the word SCRAM as used in the nuclear industry.

## Clause 11.2.8: Text and Meaning

But, oh, I've got another story. I mentioned in our cold intro Mr. Vic Maggioli, who told me a great story about the origin of the Clause 11.2.8, as it is currently written in the IEC 61511 standard. And I first got this story from Vic Maggioli himself back in the mid-90s. I think we were at the ISA 84 committee meeting that happened in Albuquerque. I digress. I'm kind of going off a little bit. But he explained why he wanted the manual means clause written the way that it was. And, you know, at the time, it made a lot of sense. Today, not quite so much. But we'll get there.

Let's begin, though, by talking about what does the clause actually say.

So Clause 11.2.8 states, Manual means, for example, an emergency stop push button that is independent of the logic solver shall be provided to actuate the SIS final elements period. You know, I think you're kind of getting the point now that whenever I actually say the word period, that the period's not actually there in the clause. So it's definitive up until the point where it says, unless otherwise directed by the SRS. So manual means, independent of the logic solver, shall be provided to actuate the SIS final elements, unless otherwise directed by the SRS.

Okay, so let's talk about the big picture in terms of what this means, how you can do it, why you'd want to do it. Well, the bottom line is, the safety instrumented system is supposed to trigger actions. It might trigger the shutdown of a pump. It might trigger the closure of a shutoff valve. It might trigger the opening of a depressuring valve. But what if the safety instrumented system, for whatever reason, is not able to do what you're asking it to do? So the safety system detected that the pressure went high, and it just never triggered the valve to go, the depressuring valve to go open.

Um, well, this is kind of tough, because, well, number one, this standard, and this clause first appeared in the OG 1996 version of ISA 84, which is the precursor to the IEC 61511 standard. Thank you, the rest of the world. Or you're welcome, the rest of the world, for the work that we in the U.S. committee did.

Um, but it requires you to do something that's kind of out of scope, which is the manual shutdown is, well, it's part of the equipment, but ultimately, and we've had this discussion many times already, a safety instrumented system, according to almost everyone who's a practitioner, is a fully automated loop. So basically, our fully automated loop failed. Now we want to put in manual means to basically do the same thing. So, um, it says that you need to install these unless otherwise directed by the SRS.

So right in the clause, you've got this gigantic get-out-of-jail-free card that, I mean, there isn't even a note that says you need to justify why you're not going to do manual means. If all that your SRS says is that we are not going to implement manual means in this SIS, you're compliant with the standard. You don't need to justify it. You just need to say that you're not going to do it.

## Mechanisms for Manual Shutdown

Okay, so now, there are a lot of different mechanisms by which you can actually perform this manual means. You can have, the lightest weight mechanism to do this is just put a target on your DCS operator interface that allows you to, um, you know, it's going to communicate to the SIS logic solver to send the final elements to their safe state. Now, that doesn't specifically meet the requirements of this clause because it says that that manual means needs to be independent of the logic solver. So there's a story coming here where the logic solver didn't work. The logic solver froze.

Now, what do I do? I need to basically be able to manually pull power off of final elements. So, uh, even though the DCS target communicating digitally to the SIS to bring you to a safe state is a mechanism to do this, it kind of doesn't meet the intent of this clause. But we'll talk about, you know, like when we get right to the end, why that's still such a common way to do this because things are not the same as they used to be.

Now, uh, another mechanism would be hardwired buttons that still communicate with the SIS logic solver. And those hardwired push buttons, maybe they're physically wired electrically to the logic solver, or you might have a remote communication between a physical switch in the control room and then digital communication out to the SIS logic solver.

That digital communication is going to be a little bit tighter, a little bit more secure, a little bit more reliable than the operator interface communication because it's basically remote IO, uh, which could be, you know, completely SIL 3 certified, uh, if everything is all in one logic solver. So that's a second way to do it is a physical switch, um, that is either physically connected or using remote IO connected to the SIS logic solver.

Now, both of those mechanisms don't meet the requirement of this clause because, well, they're not independent of the logic solver. Now, what can we do that is independent of the logic solver? Well, we can have a two position switch or a push button switch that's spring return or a push button switch that's not spring return. Uh, I talked in the last episode of the wide variety of switching mechanisms that are available, but if that switch resides between the SIS logic solver's output card and the physical device in the field, now you're independent of the logic solver.

So a lot of what I originally recommended back in the late 90s, early 2000s was the use of a two position selector switch with a normal state, a normal position, and then a shutdown position. In the normal position, you have continuity from the logic solver out to the final element. Uh, in the shutdown position, you open the contacts between the SIS logic solver and the field device. So you're basically pulling power off of the field device. This is going to work whether that field device is a valve or a pump, a pump, motor starter pump, you know, anything.

Basically, you're just pulling the power.

Now, a little pro tip here, if you're going to do that, your logic solver has no idea that you just de-energized an output. So you might want to let the logic solver know what you just did. So, um, in, in, in this, uh, kind of mechanism, you'll have multiple sets of contacts off of your switch. So one set of contacts is actually, uh, switching the power out to the field. And you can have another contact block where you're going to apply power or remove power, however you want to do it, to the input card. And that input card is simply telling you what the status of that switch is.

So if I put the switch into the de-energized position, uh, I am going to communicate that back to the logic solver by energizing or de-energizing an input saying, hey, somebody moved the position of the shutdown switch, thus take whatever action that you would want to do based on the fact that somebody just put a final element into its safe state.

Now, that mechanism is the most elegant way to meet the requirements of clause 11.2.8 because we're going to de-energize power to the SIS final element. We're going to do it one final element at a time so it's very well controlled. Uh, we're going to communicate that information back to the SIS logic solver so that I have a, a, a, a communication that allows me to move the process to a known safe state if somebody does decide to use that manual switch.

Well, what's the problem with all this? Well, it is buku expensive. Very expensive. Um, and where the heck do these switches reside? Especially now that, um, our control rooms are a mile, mile and a half away from the process. Um, you're either going to need to put this switch in a remote instrument enclosure in the field, uh, or you're going to need very, very, very, very long, expensive copper wires, or you're going to need to do some digital communication from the control room back. And anytime I'm doing digital communication, well, there's going to be a logic solver involved.

So do you have a separate logic solver just to do the communication? Uh, yeah, I don't know. Okay. So something to think about. That's kind of the original thought process circa the late 80s, mid 90s about how to elegantly implement 11.2.8 manual means. We're going to have a physical switch for every output valve, uh, or every output. And we're going to run that back to the input.

## Reducing Manual Means Cost

Now, what can we do to reduce costs? Well, if I were going to, and I, and I, there's going to be a whole lot of ifs because no new designs, it's very rare that anybody would actually do that because it is so cost prohibitive. And you really need to think about the actual risk that you're mitigating by implementing this type of system. So a lot of what's happening now, um, well, actually, let me, let me step back. So, so before I get into what's happening now, um, let's talk about other mechanisms for, uh, kind of reducing my count.

Well, number one, do I really need to have this for every single one of my final elements? So what I recommend when you're developing your safety requirement specifications, which is when you're going to start looking at manual means, look at every SIS final element and ask yourself two questions. Number one, does having a manual means of shutdown do anything for me? So if you're looking at a turbine overspeed, is a manual switch to shut down your turbine provide you any value?

Well, you have to look at the scenario which says, the reason I'm going to hit this switch is because my SIS didn't work. Well, if your SIS didn't work and you're overspeeding, you're probably going to destroy, you're going to self-destruct your turbine in, like, maybe even under a second, which does not give the operator any, I mean, we want 10 to 20 minutes for our operator. We're giving them less than a second. Uh, so, maybe there are final elements where manual means of shutdown provides no value. So we're not going to install it at all.

Um, if you're not going to install it, again, that's okay. Just explain why you're not going to install it in your SRS. Now, technically, all you have to do is, I'm not going to have a manual means for this final element. Put that on a final element data sheet. So if you're using Kenexis Vertigo software, you're going to have a data sheet that talks about manual means of shutdown. You can document it there. In the notes, you can also document why you're not going to install it. But strictly speaking, you don't need to explain why. You just need to explain what's happening.

Now, the other reason that you might not want to put in a means of manual shutdown would be if, uh, you can do it another way. So, for instance, let's go back to our archetype of a safety instrumented system, which is the fired heater. So let's say I have a fired heater and my double block and bleed doesn't close for whatever reason. The next question, and, all right, so, so the double block and bleed doesn't close. The operator knows, I just tried to shut down my fired heater, but I did not shut down my fired heater because the limit switches are telling me that the valves never went shut.

What can the operator do? Well, the operator can simply go to the DCS, go to the fuel gas control valve, and put that fuel gas control loop, whether it's a pressure loop or a flow loop, um, into manual and set the output to zero, causing that valve to go closed. So you might be able to accomplish the same thing as the safety instrumented system by manipulating valves in the basic process control system.

So, if you're going to do that, it's perfectly fine. It's compliant with clause 11.2.8. You simply need to document what you're doing. So go into your final element data sheet in Vertigo and explain how you, you know, what you're going to do instead. So I'm going to allow the operator to put PIC247 into manual and set the output to zero, which will have the same effect as closing the SIS valve. So, you might not need it. You might be able to do it with BPCS equipment. So that's going to limit the number of the actual items that you need.

## Master Trip Relay Approach

Now, even this could be prohibitively expensive, especially if you have that control room that's a mile away from your plant. So, what else can we do to get to a safe state? Well, sometimes in order to be compliant with the standard, give ourselves a little bit of comfort, we could do things that are a little bit more rough and ready.

So, a lot of processes have a master shut-off relay. And, if you go and historically look at the boiler standards, the boiler control standards, there's going to be a master fuel trip relay where if you de-energize this relay, it's going to basically move every output to its safe position. Now, a lot of process plants are going to have that same type of master trip relay associated with the watchdog timer.

If the watchdog timer times out, my logic solver has failed, so I'm going to send all my output to the safe state by de-energizing the master trip relay. Well, what is the master trip relay doing? Ultimately, if you go back, if you look at the wiring diagrams for your SIS and you go backward far enough, you're going to find one wire that is being jumped to a bunch of different locations to send power out to the field. So, somewhere at the very beginning of your power distribution, you will be able to lift one wire and prevent all power from going out to the field.

Well, instead of lifting that wire, we can put a knife switch onto the back plane of the SIS logic solver. So, if you're looking at your terminal blocks, take that main power that you're going to distribute everywhere else and put in a knife switch where if someone goes in and manually lifts that knife switch in the control cabinet, you're going to remove all the power that's going out to the field in one fell swoop. That, guess what, is very inexpensive. I think these switches, I don't know, maybe a dollar, maybe two dollars. It's pretty easy to install.

The downside of using this type of switch is when you flip the switch, you're shutting down the whole plant. You're not doing one final element at a time. Your whole plant is going to come crashing down. The second downside of this approach is, well, you have to go to the control cabinet where power is being distributed. So, you have to know where to look. You have to be trained where to look, where is the switch, how do I flip it? You need to have access to the cabinet, plus somebody's going

*[inaudible]*

go to that cabinet. So, if the plant's rocking and rolling and ready to explode, someone has to raise their hand and say, yeah, I'm going to run out to the field and I'm going to go flip that switch.

And according to Clause 11.2.6, you have to make sure that somebody is going to be willing to do this, that it's a safe, sane, and rational thing to do.

## Future of Clause 11.2.8

Alright, so those are the manual means of shutdown. Those are, I've just presented a wide variety of options to you. Some of them are currently being used. Some of them are kind of historic. But they all meet the current definition in Clause 11.2.8.

But not many people are actually meeting the historical definition of Clause 11.2.8. They would not meet it if you took out the phrase, unless otherwise directed by the SRS. Because a lot of people are relying on the logic solver for manual means.

In fact, I've mentioned before, I am on Committee 65C with the IEC, so I am involved, intimately involved in all the discussions for the IEC 61511 standard. And I know that in the next version of the IEC 61511 standard. So I am talking to you on July 14th, right now is when I'm recording this, in 2025.

Clause 11.2.8 is going to be changed. It's going to be watered down. It's barely going to exist anymore. So it's going to, I'm not going to give you the exact text. I don't know it off the top of my head, but it's going to be kind of watered down to definitely remove the phrase independent logic solver. Independent logic solver is just going to be straight up gone. And it's, yeah, you might want to consider putting in a shutdown switch. That's pretty much going to be it. Hey, yeah, maybe you might want to put in a manual shutdown switch.

Well, why is this probably okay? why is this the way that most people are designing their safety instrumented systems? And why is Vic Majoli's advice that he gave to me and the story that he told me no longer relevant? And the answer is because PLCs are much, much, much, much, much better than they were in the 1980s at the time of the story.

## Vic Maggioli Plant Failure Story

So let's get to the story. The story begins, and this is the story, once again, apocryphal or true. Anyone who has been in my training classes knows that I tell these stories and I believe that the stories get a lot more interesting and a lot more colorful as time progresses and may, at this point in time, after my retelling them several hundred times, have no relation to the actual story that I was told. So, you know, take it all with a grain of salt.

But, Vic Maggioli, a former DuPont engineer who is responsible for SIS engineering at DuPont, he worked in the kind of Philadelphia, Delaware, New Jersey kind of area. Specifically, I do believe he was in a plant at Delaware. And Vic Maggioli, God rest his soul, was the original godfather of the ISA 84 standard, the 1996 version that came out, and was the director of the ISA 80, or the chairman of the ISA 84 committee for a very long time. Unfortunately, he has passed away.

God rest his soul, great guy, fun guy, great guy to work with, and really got me personally really involved in the committee when I was very young, handed off a whole lot of work to me because he saw that I had kind of a head of steam and I was willing to do a whole bunch of volunteer work.

So, Vic and I and a couple other people, I don't remember who they are, having dinner after committee meetings, I believe this was in Albuquerque in the mid-1990s, but I don't know, you know, there were a lot of committee meetings in a lot of cities around the world. So, Vic says, I ask, Vic, why do you need the manual means to be independent of a logic solver? And the answer to the question, he says, well, what if your logic solver fails, and it fails such that all of your outputs are energized? What do you do? And I'm like, Vic, that's not possible.

And he said, oh, not only is it possible, it happened to me, and it almost was a catastrophic destruction of the entire plant. So, then he sat down to tell me the story.

So, the story begins on a cold and rainy Monday. Was it cold and rainy? I don't know. It's a much better story if it's cold and rainy. So, Monday morning is coming in after what I expected was a very, very good weekend. Maybe there was, you know, some, maybe the Eagles were playing in a, you know, very tense football game. Lots of beer, lots of wings.

And, you know, Monday morning rolls around and the crew is coming into the plant, which, you know, of course is running 24-7. It's a chemical plant, but now I've got my day shift engineering staff is coming in to try to, you know, keep their eyes on what's going on in the plant. So, as happens on Monday mornings, we've got the people going into the kitchenette and firing up the extra strong dark coffee to get a little bit of fuel going to kind of dust the cobwebs of the weekend off so that we could get back to work.

Now, the plant is just humming along and somebody, we don't know who, might have been operations, might have been engineering, you know, they're not feeling too good on this Monday morning and, well, they have to go use the facilities, the room of comfort, the restroom, they need to go putty. So, they go to the bathroom and, well, not to put too fine a point on it, they had to go number two, they had to exude some solid waste, shall we say, and they did a very good job of exuding solid waste to the point where they plugged up the toilet.

Now, you're probably wondering, Ed, what the hell does this have to do with an SIS failure? Bear with me. It's important. I'm getting there. So, you know, they did their business, cleaned themselves up, hit the flush, left. Well, you know, after a bunch of beer and a bunch of wings, things got moving, things got plugged, and, well, they never made their way out of the toilet, and all of a sudden this toilet is overflowing and it ain't stopping. So, I've got water rushing over the rim of this toilet and it's spilling out onto the ground.

Now, facility siting is not the best today, but as you go back in time, facility siting was worse and worse and worse and worse. And guess where this toilet was located? Well, it was not on the first floor. It was on the second floor. And so, the toilet's overflowing. It's kind of, water's accumulating. It's finding a low point. And the low point is going to kind of work its way. You know, we never designed anything to be watertight. So, it found a place where it could start dripping down into the first floor.

So, you'll want to speculate what was on the first floor underneath where the water collected. Yeah, that's right. the rack room and the marshaling cabinets for our chemical plant.

So, the marshaling room and all the cabinets for the safety instrumented system are directly below where the water has accumulated. And now the water is drip, drip, drip, drip, dripping onto the top of our cabinet. Well, you know, we've got all kinds of design specs for our cabinets. We can make them waterproof, but this is inside. We never decided we were going to make our cabinet waterproof. So, eventually, enough water dripped on the top of the cabinet. It kind of started to work its way toward the back of the cabinet and now it's drip, drip, dripping on the PLC rack.

Now, those of you, which I assume is all of you who are familiar with electronics know that water and electronics don't get along very well. Water is generally conductive and water in a lot of cases is going to cause a short circuit. So, what happened? The water dripped, dripped, dripped, dripped on the cabinet and it caused the PLC outputs to energize.

Now, these are OG 1980s, some of the first PLCs that were ever built. Diagnostics? What for? We don't even know what diagnostics are yet. so, no diagnostics or extremely minimal diagnostics to tell us that our PLC output card, not only has it failed, it has failed in such a way that I have energized every output and I have no way to shut the plant down. There's no way to de-energize the outputs in the field, so all my SIS valves are now frozen in the dangerous state. That's the failure that has occurred. And, furthermore, all kinds of other things have happened.

I mean, we're dumping water into the control room. So, the basic process control system starts to go wonky. It's opening valve, it's closing valves. The process is going haywire. The engineering team has now dropped their cups of super strong coffee. They're scrambling around the control room going, what the heck is happening? The SIS should be shutting down but none of the SIS valves have closed. What do I do? What do I do? What do I do?

So, eventually, somebody's like, something's wrong with the SIS. They run back into the rack room and they see that there's water, water everywhere. And, oh, the SIS didn't work. To quote, oh, who was that? Oh, the boards did shrink. Oh, his name is not. Somebody drop in the comments who the poet is that wrote the rhyme of the ancient mariner that I was quoting there. But I digress. I'm really going off on a tangent today.

So, now, the SIS team, including Mr. Victor Majoli, is like, what do we do? We need for our SIS to put everything into a safe state, but the SIS has failed in such a way that I can't. Wouldn't it be nice if I had manual means independent of the logic solver to move those SIS final elements to the safe state? But he didn't. So, what did he do? What did they do? Being top notch SIS engineers who know their electronics, they went into the rack room. They flew open those cabinets.

They got wire cutters or maybe with their bare hands they just started ripping wires out to just manually pull power out to the field. And eventually they were able to rip enough wires or cut enough wires to de-energize all those final elements out in the field and finally get the plant to a safe state.

So, once again, apocryphal or true, probably leaning

*[inaudible]*

apocryphal every time I tell the story. But the baseline, the bottom line of the story is there was a failure of the SIS logic solver that caused all valves to stay energized and that was a big honking problem. And making sure that that doesn't happen to your plant is very, very important.

## Modern PLC Diagnostics Mitigate Risk

Now, what has changed since the mid-1980s to 2025? Well, we've got 35 years, 40 years, 35 years, 35 years of improvement of SIS design.

Number one, if the logic solver output would fail like that today on a SIL 3 certified logic solver, there are all kinds of diagnostic switches that would shut you down automatically, that would diagnose this failure and shut you down automatically. So, with today's safety PLCs, the failure mechanisms that I just described to you are, they're just basically not physically possible anymore.

So, if you're using a well-designed, well-installed, well-maintained, SIL3 built logic solver, it's the frequency at which this type of failure could occur is so vanishingly low that its risk is tolerable right out of the gate.

So, that's kind of a statement that, you know, even with the change that's upcoming in the standard, I would request that you still document in your SRS.

You would say that we have considered the need for manual means of de-energizing final elements independent of a logic solver and because of the low failure rate of the SIS logic solver, you can even put in a number, and the high degree of diagnostics to detect failure and automatically bring the process to a safe state, we are not going to apply manual means in the independent of the logic solver and instead you're going to document what you are doing for manual means because there are a lot of situations where you still would like a switch to push.

and again, now if you're going to say that your SIS logic solver is completely fine, now maybe I can hardwire to inputs in the SIS logic solver that are either hardwired or hardwired to remote IO, which are going to be safely digitally communicated to the SIS, maybe we're going to use an SIS target.

So today, the SRS task is more of an issue of thinking about what you need or thinking about what you want in terms of manual switches and documenting what you're going to do. that whole requirement of independent logic solver is something that's not really that big of an issue if you document it today and the next version of the 1511 standard isn't going to have the phrase independent logic solver at all. So, you know, going forward

*[inaudible]*

you're not going worry about it.

## Sector Standards Caveat

Okay, now, before I leave this topic, one thing that I will tell you is that just because IEC 61511 doesn't require you to have a hardwired independent of the SIS logic solver manual shutdown switch doesn't mean it's always okay.

And here, I'll go to boilers specifically. So, you look at boilers, you're going to be following NFPA, in the US, you're going to be following NFPA standards for boilers usually. Some cases you won't. It's a topic for another day.

But, those sector specific or equipment specific standards might still require you to have things that are hardwired and independent of the logic solver. And just because IEC doesn't require you to do it doesn't mean something else won't require you to do it. So, as always, look real hard at those sector specific standards that are going to sit on top of the IEC 61511 standard and make sure that you're right with those sector specific standards also.

## Episode Wrap-Up and Preview

Okay, almost an hour that we've been at this and I have just talked about manual means. One sentence of the standard took about an hour of discussion, but, you know, a couple of really, really good stories. The Vic Maggioli water story, water, contaminated water, shall we say, and the good old safety control rod Axeman urban, I'm going to go on that one and even call it an urban legend, but good stuff there.

Okay, next week, sit tight because we're probably only going to talk about two clauses next week. Those are going to be 1129, 11210, which have to do with independence between the SIS and BPCS, or lack thereof, and justification of the lack thereof. Specifically, 11.2.10 is such a loaded clause that it will require, basically, its own entire episode. So, come back next week. We're going to talk about 1129, 11210.

Until then, everybody keep safe. Talk to you later.

## Kenexis Vertigo Software

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 lifecycle using the Kenexis integrated safety suite and our SIS safety lifecycle 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. Thank you.