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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E6 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 6: IEC 61511, Clauses 3.2.35 through 3.2.42 (Logic Solver, Mode of Operation, and Risk Reduction Definitions)

—

## Introduction and Podcast Overview

The logic solver, also known as a PLC or a DCS, is the part of the SIS that does the thinking.

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.

## Logic Solver Definition (3.2.36)

All right. We're going to pick it back up in still in the definition section. There's a lot going on in the definition section, a lot to discuss. We're going to start with 3.2.36, which is logic solver. So logic solver is part of either a BPCS or SIS that performs one or more logic functions. So it's the part of the SIS that does the thinking. It takes the inputs, reads them, makes decisions about what to do, and then makes commands to the final elements based on that decision-making process.

Now, logic solver, as it's defined here, is going to apply to BPCS or SIS. But then again, you know, with regards to safety instrumented systems, we're generally going to be talking about a safety PLC. But it also might be a single-loop PLC or a single-loop programmable system. It could be a series of relays. There's a lot of different things that it can be.

All right, note one to the entry. In IEC 61511, the following terms for logic solvers are used. Electrical logic solvers for electromechanical technology. Electronic logic systems for electronic technology. And PE logic systems for programmable electronic systems.

Okay? Actually, there's a lot more ways to do the logic than that. You've got pneumatic-based relay systems. You have magnetic logic systems. And sometimes you have no logic solver at all. You just direct hardwire your inputs to your outputs. So, logic solver is very broad and very generic.

## Safety-Configured PE Logic Solver (3.2.36.1)

Note 2 to the entry says, Examples are electrical systems, electronic systems, programmable electronic systems, pneumatic systems, and hydraulic systems. Sensors and final elements are not part of the logic solver. All right. So, in the second note, we kind of went out of the realm of electronics and basically said, it doesn't matter what's doing the thinking. It's called the logic solver. And it's going to be covered in the standard if it's used for safety instrumented system.

All right.

A subset of that, 3.2.36.1, safety-configured PE logic solver. We're going to discuss this in a lot more detail in Clause 11.5, where we talk about the full range of considerations and thinking that needs to be done when you're making decisions about what types of equipment can be used in a safety instrumented system. And there's a whole lot of rules around logic solvers. Ultimately, what we're going to learn in Clause 11.5 is you can't just take anything off the shelf and put it in your safety instrumented system. It needs to either be designed and manufactured in accordance with IEC 61508.

So, the vendor has followed all the rules in IEC 61508. The shorthand code for that is certified. Because most equipment vendors that go to the trouble of complying with IEC 61508 in their design and manufacturing processes would also get an independent third party to vouch for it. Instead of expecting you to trust them. But also note that nowhere in the standard anywhere does it require anything to be third party certified.

So, sometimes as this podcast progresses, I'm going to say certified. What I meant is designed and manufactured in accordance with 6508, whether or not the equipment vendor actually went to the trouble of getting a third party certification of that.

So, certified or prior use experience. So, if the device is not certified and you want to use it in a safety application, you're going to need to have experience with that device in the application that you're looking at that is successful so that you have a good feel for that device's ability to do the job. So, what that kind of leaves out is you can't just pull something off the shelf that you've never used before and say, yeah, the first time I ever try to use this type of device, I'm going to put it in a safety application. That is not allowed by the standard.

Now, prior use or certified, if you're using, going with that prior use experience kind of mindset on the PLC side, there are going to be a whole lot of limitations and you're going to see that you're going to get limited to SIL 2 and even that is going to be very hard to achieve. But when you're using a non-certified, using the shorthand PE logic solver, you need to take some extra steps to make sure that it's safe. And those extra steps that you need to do in the design and configuration of that general purpose PLC is called safety configuration.

So, a safety configured PE logic solver is a general purpose industrial grade PE logic solver, which is specifically configured for use in safety applications. Note one, further guidance can be found in 11.5 and oh boy, is a lot of guidance going to be found in 11.5. Basically, you need to do the equipment vendors work for them and basically figure out everything that could possibly go wrong, all the failure modes, and then engineer ways to detect that that failure mode is present and automatically take the logic solver to a safe state.

So, more on that coming up in 11.5. I've got a lot of discussion ready to go for that topic.

## Maintenance and Engineering Interface (3.2.37)

3.2.37, maintenance and engineering interface. It is defined as the hardware and software provided to allow proper SIS maintenance or modification. This is the software that you use to program and configure the PLC. You use it to configure the I.O. cards. You use it to configure the logic solver. You use it to write your ladder logic or your function block diagram code, upload stuff, download stuff, and so on. And in the interfaces section of clause 11, we're going to give you some requirements for that piece of equipment and what you need to do to make sure that it's safe.

Just drop in a little bit of a tease. A lot of people are not using their maintenance and engineering interface properly, especially for like SIL 2 rated PLCs or uncertified PLCs. There's an onerous requirement that most people don't follow that they really should be to be in compliance with the standard. So, we'll come back to that.

## Mean Repair Time and Mean Time to Restoration

Note one to that entry. Okay, moving along. 3.2.37.1, which is very odd because the .1 has nothing to do with 3.2.37. It's just a matter of running out of space and just sticking on a number to insert into the standard. So, 3.2.37 starts a series of definitions and acronyms that are going to be familiar to you when you start running calculations for probability of failure on demand.

These are terms and acronyms that are going to be used in your SIL verification calculations for availability, unavailability, reliability, unreliability. The first one, 3.2.37.1 is mean repair time or MRT. It is defined as expected overall repair time. And the note to the entry is that MRT encompasses the times B, C, and D of the times for MTTR C3.2.37.2, which is the next definition that we're going to get to.

And we'll cover what those are. Well, actually, I'll just tell you that B is the time spent before starting the repair. C is the amount of time that it actually takes to do the repair. And D is the time that the component is put back into operation. Now, MRT, mean repair time, is a term that we use in the standard that can easily be confused with MTTR if you think that MTTR means mean time to repair. To some people, it does.

In some contexts, it does, which is why you have to be extremely careful when you're running calculations and talking to people when they say MTTR to get a very precise definition of what they mean. So the MRT is actually the amount of time that it takes to do the repair. I get an alarm saying my device is in the failed state. So maybe it's a detected failure or maybe I ran a test and figured out that it's in the failed state.

Once I know that it's in the failed state, well, I need to go collect all my equipment. I need to fill out some paperwork. I'm going to need to go talk to the operator to be able to go out into the field. I'm actually, maybe I'm going to need to go to the warehouse to get some spare parts. Then I'm going to walk out to the field, check everything out, take the device out of service, repair it, replace it, whatever, test it to make sure it's working, and then put the device back into service. So that's the mean repair time, MRT, the amount of time that it takes to repair.

This is different from 3.2.37.2, which is the MTTR. And in accordance with IEC 61511, MTTR means mean time to restoration, not mean time to repair, mean time to restoration. The MTTR, mean time to restoration, is a holistic number that includes everything, all the time periods and all the tasks that elapsed between when the failure actually occurred and when the repair is complete and the process is back in service. The difference between the MRT and the MTTR is item A of note one to the entry, and that's the time to detect the failure.

So what time elapsed between when the failure occurred and when I know that the failure is there?

And that mean time to restoration is going to be a function of how often you test it and whether that's a manual test or that's an automatic diagnostic. So in the land of unavailability and availability where everything is a mean, everything is an average, the average amount of time that the device is in the failed state before you know that it's in the failed state is the diagnostic test interval divided by two. So if I test a device once a week, then on average, that device will have been in the failed state for half of a week before you know that it's in the failed state.

So that term is going to come into play when we're running our unavailability calculations, which depend on mean time to restore. But when you see the calculations, you'll see that we break it into mean repair time plus the mean time to detect, which is half of the automatic diagnostic interval.

Diagnostic interval. Now that automatic diagnostic interval is probably going to be insignificant for sensors and logic solvers because, you know, if you test something once a second, then half of that is half a second. And if you add that to a 8 or 24 hour or 48 or 72 hour repair time, you're pretty much just back to the repair time. But a slower diagnostic like a partial stroke test of a valve, that might not happen but once a week or once a month. And that diagnostic test interval becomes important when you start running your calculations. All right.

## Maximum Permitted Repair Time (3.2.37.3)

Next item is MPRT. So what the heck is the difference? All right. 3.2.37.3. We just talked about the MRT, mean repair time. Now we're talking about maximum permitted repair time. What's the difference? Why did I need two definitions? Well, we wanted to be very clear when we were writing the standard that when you're running your calculations, you're actually going to want to use an MPRT, maximum permitted repair time. So what does that mean?

That means, well, I'm going to allow myself 72 hours to perform the repair, even though I could probably get it done in four hours. But I don't know for sure, depending on what the day is, what spare parts I have, what staffing levels I have. I might not be able to do it in four hours, even though that's what I expect. So when running your calculations, you'll kind of generally give yourself a little bit of a cushion and go with a maximum permitted repair time or MPRT instead of the mean repair time that you actually think it's going to take to do the repair.

So the definition for MPRT is maximum duration allowed to repair a fault after it has been detected.

Note one to that entry is that the MRT may be used as MPRT, but the MPRT may be defined without regards to the MRT. A MPRT smaller than MRT can be chosen to decrease the probability of a hazardous event. A MPRT greater than MRT can be chosen if the probability of a hazardous event can be relaxed.

Okay. Basically, MPRT, MRT don't necessarily have to be related to each other. Note two to the entry. When an MPRT has been defined, it can be used in place of MRT for calculating the probability of random hardware failures. That's what I just told you about. Okay.

## Mitigation and Mitigative Protection Layers (3.2.38)

Moving on. 3.2.8. We're going back to away from verification calculations back into the risk analysis. 3.2.38 is mitigation. The definition is an action that reduces the consequences of a hazardous event. With note one to the entry being, examples include emergency depressurization or closing ventilation dampers on detection or confirmed fire or gas leak or initiation of deluge on confirmed fire detection.

Mitigation. So, most of the time when we're looking at independent protection layers, when we're analyzing the risk of the plant, when we're doing a LOPA, we're considering preventive protection layers. So, a preventive protection layer, if it works, there is no consequence.

That's how safety instrumented systems work. They are preventive. If they work, there will be no consequence. As opposed to mitigative protection layers, which are going to greatly confuse and complicate your risk analysis because there's a consequence if they don't work. But there's also a consequence if they do work. It's just that if they don't work, the consequence is extreme. And if they do work, there's still a consequence, but it is at a minimum less extreme.

So, when you have a consequence mitigation and you're doing your risk analysis, things are going to get a little bit wonky, a little bit more complicated because you need to think about, well, what's the consequence if it works? What's the consequence if it doesn't work? So, mitigation is something we will get to in the layer of protection analysis.

## Mode of Operation: Low, High, and Continuous (3.2.39)

All right. Now, 3.2.39, we're going to have a few definitions. It's almost a half — no, it's more than a half page. And it's relating to mode of operation. Mode of operation is going to define how you do your risk analysis. It's going to define how you do your SIL verification calculations. And ultimately, what we're concerned with is the mathematics of probability and whether or not the mathematics of probability are valid or do we need to switch to frequency-based mathematics.

So, 99.9% plus of safety instrumented functions in the process industry are going to be low-demand mode where you consider probabilities. But I have run into high-demand mode. I have run into continuous mode. Not more than a handful, but they are out there.

And when you're in those modes of operations, you need to switch to frequency mathematics instead of probability, which means you're going to have to go into your Kenexis integrated safety suite and bust out our Arbor fault tree analysis tool to run fault trees that are going to generate a frequency for you as opposed to using vertigo, which at this point in time is limited to just doing probability of failure on demand equations for low-demand safety instrumented functions.

Okay, mode of operation is defined as the way in which a SIF operates, which may be either low-demand mode, high-demand mode, or continuous mode. And then we have ABC. So, A, low-demand mode is the mode of operation where the SIF is only performed on demand in order to transfer the process into a specified state and where the frequency of demands is no greater than one per year. I'm going to get on my soapbox in a little bit about that one-year number. They have greatly simplified the thought process, but what they're saying is technically incorrect and not necessarily true.

I'll explain in just a second after I give you all the definitions. So, high-demand mode, high-demand is the mode of operation where the SIF is only performed on demand in order to transfer to the process to the safe state, where the frequency of demands is greater than one per year. Hmm. Okay. Less than once a year, low-demand mode, greater than once a year, high-demand mode. And then C, we have continuous mode, which is the mode of operation where the SIF retains the process in a safe state as part of normal operation.

So, basically, it's a control loop, a continuous controller whose failure will immediately result in a consequence.

So, continuous mode of operation. Think of the controller that's controlling the position of an airplane rudder. As soon as it fails, you will have a consequence. So, when it fails, you're done. So, if it fails to where the rudder shoots to the side, you're going to spin your plane into the ground and crash immediately. If it fails in place, you're basically not going to be able to turn your plane and you're going to crash eventually. That's a little bit of a stretch, but you see what I'm getting at there.

The controller fails, and because the controller failed, we have a consequence. Now, mathematically speaking, the difference between high-demand and continuous mode is what I like to refer to as a distinction without a difference. Because you need to run frequency mathematics for both of those.

Now, a slight bit of difference between continuous mode and high-demand mode is that if you have very high-frequency diagnostics, that the repairs can happen quickly and the high-frequency diagnostics happen very frequently in comparison to the demands, you may be able to consider the diagnostics, the diagnostic testing when you're doing your SIL verification calc. But in continuous mode, redundancy is pretty much all you have because as soon as it fails, you're finished. Okay. Low-demand mode is probability. High-demand and continuous mode are frequency.

Why is this important? Why are you telling me this, Ed? Well, ultimately, what we're looking at is what is going to be the mechanism to detect that your device is in the failed state. So, in a low-demand mode, you're testing at a high frequency in relation to how often the demand is occurring.

So, if you test once a year but you have a demand once every 10 years, you're much more likely to know that the failure has occurred because you tested it, repaired out, as opposed to if you flip it around and say, I'm testing once every 10 years, but I'm getting a demand once a year, then you're probably going to find out that the device has failed because you challenged it and it didn't work, as opposed to testing it.

So, if you're more likely to know that the device has failed because you challenged it, the concept of probability doesn't make sense anymore because whatever the frequency of the failure is, that's basically the failure happens and then some point in time after that, you're going to get a challenge and you're going to get a consequence. Testing in the high-demand mode and the continuous mode kind of don't really matter because your test is never going to identify the failure. So, now we're just looking at how frequently the failure happens.

Now, take that with a grain of salt related to the high-frequency diagnostics. Okay, that's kind of a separate little sticky issue for the high-demand mode. Now, for the low-demand mode, you can use a probability because you're much more likely to know that a failure happened because you tested it and then were able to repair it and then there's kind of the unavailability between when it failed and when you did the test. So, a probabilistic approach makes more sense.

But you'll see in these definitions, they key everything on a year when mathematically speaking, if we were to be precise, well, that's kind of got a whole bunch of simplifying assumptions baked into it. And that simplifying assumption is that, well, we're going to test it about once a year. So, if you test about once a year, then low-demand mode, your challenges are less frequent than your tests and in high-demand mode, your challenges are more frequent than your tests. So, that works out.

But if I have a safety function, let's say I'm running a batch operation and I run 10 batches a day and I test my safety function before I start each batch. Well, if I have a demand that occurs once per year, I'm going to be testing 365 times for each time I challenge it. That's not high-demand mode. That's low-demand mode if you consider the comparison between frequency of testing and frequency of challenging. So, keep that in mind.

Take it with a grain of salt. Think about what you're doing when you're doing the design because that one-year number kind of assumes that you're testing about once every year. If you're only testing once every 10 years, that might not be a valid way to choose things. If you're testing multiple times, once a month or once a week, that kind of throws things out the window also. So, be careful. Think it through when you're assigning mode of operation.

## Demand Mode and Continuous Mode SIF (3.2.39.1-.2)

All right. 3.2.31. I'm sorry. 3.2.39.1 is the definition for demand mode. And it says a SIF operating in low-demand mode or high-demand mode. So, demand mode is basically saying we're either low-demand or high-demand. Wow. Really? Really? We needed this definition? Well, no. We probably didn't need this definition, but the definition was probably put in here because we have a raft of notes.

So, the notes for demand mode SIF. Node number one. If the event of a dangerous failure of the SIF, a hazardous event can only occur, number one, if the failure is undetected and a demand occurs before the next proof test, or two, if the failure is detected by the diagnostic tests, but the related process and its associated equipment has not been moved to the safe state before the demand occurs.

Okay.

That's a little elaboration of what I told you. Actually, what I told you is kind of an elaboration of the note, to be honest. Note two to the entry. In high-demand mode, it will normally be appropriate to use continuous mode criteria. So, basically, they're admitting that, you know, continuous and high-demand mode is generally a distinction without a difference because you're going to use the same analysis process to pick SIL targets and the same SIL verification method a lot.

Note three to the entry says that the safety integrity levels for SIF operating in demand mode are defined in tables four and five. Tables four and five are going to show up in clause 11, and they define what, numerically speaking, the safety instrumented functions are. We will spend a decent amount of time on that. All right.

3.2.39.2 is a continuous mode SIF, which is defined as a SIF operating in continuous mode. A definition that is that circular should not even be legal. Well, not that it's a whole lot better than 3.2.39.1, but hey. Well, once again, we've just got a raft of notes, three notes. Note one. In the event of a dangerous failure of the SIF, a hazardous event will occur without further failure unless action is taken to prevent it within the process safety time.

So we're basically saying when the failure occurs, we're going to get the consequence unless you can, you know, immediately do something about it. Note two says continuous mode covers those SIF which implement continuous control to maintain functional safety. So it's a controller in reality, not a shutdown. And note three, safety integrity levels for SIF operating in continuous mode are defined in table five. So when we're talking about table five, it's all frequency-based, whereas table four is going to be probability of failure-based.

And again, we'll talk that one into the ground once we get into clause 11.

## Software Module Definition (3.2.40)

All right, a little bit more here. 3.2.40 talks about a module. Pretty simple definition. Again, when we're talking about a safety instrumented system, it is a collection of equipment, a collection of system, and a collection of modules.

So module, if you use that term, is defined as a self-contained part of a SIS application program. Okay, so module, we're talking about programs and modular programming design. Can be internal to a program or a set of programs that performs a specified function, such as a final element start, stop, test sequence, and application-specific sequence within a SIF.

So modular design of programming is something we will get into in clause 12. And it's kind of interesting because module is also used very frequently for hardware, an input module, a CPU module, an output module, a power supply module. But the only definition that's contained in the standard is the one for software.

A couple of informative notes. Note one, in the context of IEC 61131, part three, a software module is a function or a function block. So for those of you in the know, those of you PLC programmers out there will know that the 61131 standard defines programming languages for PLCs, kind of higher-level programming languages, and we are going to refer to them in the standard as limited variability languages. More on that. A lot more on that. We've already talked about that a lot, but there's going to be more continuing on.

Note two to the entry, most modules have repetitive usage within an application program. So it's kind of like a subroutine that you don't just use once, but you're going to call it many times over and over and over and over.

## MooN Voting Architecture (3.2.41)

Something that, for instance, is going to convert a number of bits in the PLC into an engineering unit value is something that you could write a subroutine or a module for. Okay, let's keep going. A couple more. 3.2.41 is the definition of M-O-O-N, and those are capital M and capital N and little O's. And that's kind of the generic for one out of one, one out of two, two out of two, two out of three, two out of four, three out of four. It's the two O's, lowercase O's, are out of.

And we're defining that as SIS or part thereof made up of N independent channels which are so connected that M channels are sufficient to perform the SIF. So the N is how many devices or how many channels do I have? And M is, well, how many of them have to vote to shut down in order for the shutdown to occur? So if I have two out of three voting transmitters, the N is three. I have three independent channels or three devices and I need for M or two of them to vote to shut down to make the shutdown happen.

## Necessary Risk Reduction and Episode Wrap-Up (3.2.42)

All right. One more quick definition. A necessary risk reduction is the risk reduction to be achieved by the SIS and or other protection layers to ensure that tolerable risk is not exceeded. So necessary risk reduction is the gap. So when you're doing your LOPA study, you're doing your hazard and risk analysis trying to determine how good your safety instrumented system needs to be. The gap between where you calculate the risk and where the risk needs to be, the tolerable risk level, that gap that you need to close by assigning protection layers is your necessary risk reduction.

All right. With that, I'm going to close out the episode for this week.

We've got a lot more definitions to go, but I did want to get a few more to you. Try to break it into a little bit more of a manageable chunk. We'll come back next time and hit 3.2.43 where we start talking about definitions for programmable systems.

## Vertigo Software for SIS Lifecycle Management

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.