Functional Safety Podcast: episode (S1E4) is now available

Introduction and Episode Disclaimer

All of the court intrigue, all of the personalities, all of the fights, all of the politics happens in the definition section. 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.

Last time, we ended with definition 3.2.5. We are still in the definition section of the standard for sure, and there’s a lot to cover here in the definitions. All of the politicking, all the intrigue happened right here. So let’s pick it back up with 3.2.6, which is common cause. And you’re going to get a.1 and a.2 definition. The first one for common cause failures and the second one for common mode failures. There’s a lot of definition of common cause, something that is barely discussed in the standard. And it is a very important part of the SIL verification calculations.

But the calculations really aren’t covered in the standard. The amount of information you get about the calculations is actually pretty minimal. And you need to go to other resources outside the standard to learn more about that. Nevertheless, let’s hit the definitions.

Common Cause and Common Mode Failures

3.2.6.1. Common cause failures. Concurrent failures of different devices resulting from a single event where these failures are not consequences of each other.

So a common cause failure, a better definition that I would use is when you have a redundant system and all of the redundant components fail at the same time for the same reason. That’s a common cause failure. So if you have a lightning strike that burns up a 2 out of 3 vote of pressure transmitters because it struck all 3 of them, that’s a common cause failure. Or you have 3 pressure transmitters that are all connected to the same process tap and it plugs. That’s a common cause failure. And it’s something that is real.

It’s something that needs to be considered when you’re running your calculations.

All right, note 1 to the entry says, All the failures due to a common cause do not necessarily occur exactly at the same time. And this may allow time to detect the occurrence of the common cause before a SIF is actually failed. So that’s a great lead-in or the example of tap plugging was the lead-in. That’s something that takes time to develop and it might affect one transmitter before it affects the others.

Note 2, common cause failures can also lead to common mode failures. Okay, fine. We’ll get to common mode failures in just a second. Note 3, the potential for common cause failures reduces the effect of system redundancy or fault tolerance. E.g. increases the probability of failure of two or more channels in a multiple channel system.

This note, when I’m teaching, I like to say that common cause failures are nature’s limitation to the effectiveness of redundancy. So when you just look at the probability math, multiplying probability of failure together of multiple components, you could get astronomically small probabilities of failure if you ignore common cause. But you can’t ignore common cause. And there’s kind of a limitation that says, well, if I have one transmitter, that’s good. If I have a second one, that’s dramatically better. The third one, though, I’m only getting marginal benefit out of.

And that fourth one, you’re not going to see any difference in performance because common cause is already dominating in a one out of two vote. It’s ruling in a one out of three vote. And in one out of four, it’s the only thing that really matters. So some of the other factors don’t come into play whatsoever.

Note 4, common cause failures are dependent failures. They may be due to external events such as temperature, humidity, overvoltage, fire and corrosion, systematic faults such as design, assembly or installation, or human error, misuse, and so on. So common cause failures are dependent on other things happening.

And I’m going to come back to the concept of systematic failures and common cause failures because it’s really important when we start looking at the probability of human failure and how it affects the probability of failure on demand of a whole system and how we control human failures. Kind of a precursor letting you know, we don’t control human failures by running a bunch of calculations and seeing what they say. So we’ll get to more of that when we get into clause five.

Note five to the entry. By extension, a common cause failure in single form is a failure belonging to a set of concurrent failures. Wow. Wow. Wow. Some of the academics got in the room and needed to, you know, show off how much they know or make themselves seem very, very important to the discussion. So the singular form and the plural form of common cause failures. Failure belonging to a set of concurrent failures. So take that with a, no, don’t take that with a grain of salt. That is basically irrelevant to anything that you’re ever going to do.

But somebody was very proud of themselves for putting that note in.

Anyway, let’s move on to 3.62, which is common mode failures. So we talk about common cause failures. Now we’re going to get into common mode failures. Common mode failure is concurrent failures of different devices characterized by the same failure mode. Wow. Talk about a circular definition. A common mode failure is a common mode failure. What a horrible definition. Common mode failures. Now we’re looking at a concept of failure modes and effects analysis or failure modes. What is the thing that happens that causes the failure to occur?

And if that factor is present, that factor could cause multiple devices to fail at the same time for the same reason.

So why all of this discussion of common mode and common cause? It’s a little bit over the top. But it is what it is. It’s not bad information. It’s not particularly useful. But there you go. Four notes to this definition. Note one, common mode failures may have different causes. Okay. Note two, common mode failures can also be the result of common cause failures. Note three, the potential for common mode failures reduces the effectiveness of system redundancy and fault tolerance the same way that it did for common cause failures.

And note four, by extension, a common mode failure in singular form is a failure belonging to a set of concurrent failures. So the academics showed up in full force for the common mode, common cause discussion.

At the end of the day, we’re going to apply the beta factor to our calculations because we understand that a single stressor can cause multiple things to fail at the same time for the same reason, which is men’s slightly more useful definition that I will give you.

Compensating Measures for SIS Degradation

All right, let’s go into 3.2.7 is a compensating measure. Compensating measures are going to hit us right between the eyes in clause 11.3 when we’re looking at design. So let me give you the definition first. A compensating measure is temporary implementation of planned and documented methods for managing risks during any period of maintenance or process operation when it is known that the performance of the SIS is degraded.

I bring up clause 11.3 because that’s the section of the detailed design that talks about what do you do when you detect that a failure has occurred with automatic diagnostics. Well, one of the things you can do is shut the plant down. You can always shut the plant down, bring everything to a safe state. But you can also continue operating and repair out of that failure while the plant’s still running. But when you do, you need to have compensating measures in place.

So let me give you an example of a compensating measure. If I have a level transmitter whose signal was at 12 milliamps and it was steady and then all of a sudden it went to zero. Well, if you go to zero, that’s not a process measurement. Something went wrong with the loop or the device that caused it to just basically shut down. So you’re pretty confident that you don’t have a low level condition. You just have a busted transmitter. In that case, you might want to continue to operate the plant. But when you do, you need something to replace that failed functionality.

So perhaps you will send a dedicated operator out to the field to look at a sight glass and have a radio to call into the operator when the level in the sight glass gets a little bit wonky.

So compensating measures or alternate protection plans are things that you will find in our effigy. I’m sorry, our effigy. Listen to me. It’s not fire and gas mapping. Our Vertigo software, we have a bypass section where it gives you a worksheet that you can fill out to define what the compensating measures are when you put a device into bypass. Either deliberately or you may have configured your SIS to automatically bypass a failed component in a situation such as the one that I just described.

Components, Configuration Management, and Conservative Approach

Okay. Clause 328 component. Pretty straightforward. One of the parts of the system, SIS subsystem or device performing a specified function. And note one to the entry. The software guys have to pipe in and say a component may also include software.

So what you’re going to realize when you start doing your SIL verification calculations is that a SIF is built up of subsystems and the subsystems may have multiple components configured into channels. So we’re just laying the groundwork. So we’re just laying the groundwork and the definitions for what we’re going to include.

So you might consider a pressure transmitter as an SIS subsystem. But that pressure transmitter might include remote seals, the transmitter device itself. You might have an IO charm. You may have intrinsic safety barriers. All of these are components that need to be considered when you’re designing your SIS. But it’s not an entire subsystem. And it’s definitely not the entire SIF.

3.2.9 is configuration management. So configuration management is the discipline of identifying the components and the arrangements of those components of an evolving system for the purposes of controlling changes to those components. And maintaining continuity of the system and traceability of any changes through the lifecycle. Wow.

I think the phrase configuration management is clearer than the definition of configuration management. Just basically, it’s the process. It’s kind of part of management of change. Just making sure that how your system is designed is controlled as you implement it and make changes to it.

Now, the next definition was kind of shoved into here because of auto-numbering. So it’s 3.2.9.1 because we needed to insert a new definition under the Cs. And that definition is conservative approach. A conservative approach is defined as a cautious way of doing analysis and calculations. And it’s basically the way we do things in SIS engineering and safety engineering as a whole.

Note 1 to that entry is, In the safety field, each time an analysis, assumptions, or calculation has to be done about models, input data, computations, etc., it can be chosen in order to be sure to produce pessimistic results.

So the definition needed to go in there because we say do things conservatively so often, and some people might not know what that means. So basically, we’re going to overestimate the risk. We’re going to assume the failure rates are higher than they are. We’re going to assume the mean time to repair is higher than it is, so it will always produce a pessimistic result. And if you achieve your tolerable risk with the pessimistic results, you know that tolerable risk is going to be achieved.

So when we’re simplifying things, when we’re making assumptions, we’re always going to overestimate the risk and produce pessimistic results.

Control System Definition

Next definition, Clause 3.2.10, is control system. Control system is a system which responds to input signals from the process and or from an operator and generates output signals causing the process to operate in a desired manner.

Now, the definition of control system is going to be kind of a starting point because, and this is one of those things that drives me crazy, it’s going to drive you crazy about the way that definitions are laid out in the standard, is that if you want a full definition of a term, you’re going to get stepped through a bunch of different phases to get to there. So you need to understand four different definitions to really understand one term.

So 3.2.10 control system is the building block that we’re going to build basic process control system versus safety instrumented system because both the BPCS and the SIS are control systems. But then when we define those other things, we’re going to start layering things on top of the definition of control system.

So note one to the control system entry is the control system includes sensors and final elements and may be either a BPCS or a SIS or a combination of the two. Okay, so nice and vague, fundamental foundation type definition. Okay, moving on.

Dangerous Failures and Fault Tolerance

3.2.11 is finally a very important definition. And that is going to be dangerous failure. We’re going to talk a lot about different types of failures. And when we’re looking at safety instrumented systems, when we’re calculating that factor of probability of failure on demand, we’re concerned about dangerous failures.

A dangerous failure, also called a covert failure because it hides. It’s also called an inhibiting failure because it inhibits your safety function from doing what it’s supposed to do.

All right, the precise definition out of the standard is a failure which impedes or disables a given safety function. So if a dangerous failure occurs, the safety function is not going to do what it’s supposed to do.

All right, note one, a failure is dangerous only with regard to a given SIF. So dangerous versus safe isn’t kind of an abstract term. You’re basically looking at a particular safety instrumented function and asking yourself, how does this failure impact the overall SIF’s ability to perform its function?

Note two to the entry. When fault tolerance is implemented, a dangerous failure can lead to either A, a degraded SIF where the safety action is available, but there is either a higher PFD demand mode of operation or a higher likelihood of initiating a hazard event in the continuous mode of operation.

So if you have some safety fault tolerance, you may have just degraded the functionality, not removed it completely. And the B part of that note is a disabled SIF where the safety action is completely disabled in the demand mode of operation or the hazardous event has been introduced in the continuous mode of operation.

Note three to the entry. When no fault tolerance is implemented, all dangerous failures lead to a disabled safety instrumented function.

Dependent Failures and Common Components

All right, clause 3.2.12 is another extension of failures, and that is going to be a dependent failure. A dependent failure is a failure whose probability cannot be expressed as the simple product of the unconditional probabilities of the individual events which caused it.

Wow, that’s confusing. That really doesn’t tell me anything. It doesn’t tell me what it is. It tells me what it’s not.

Okay, in a dependent failure, two things are related to each other. What we’re basically saying is event A and event B are related to each other in some way, and you can’t look at them independently. So just simply modifying the probabilities together is not, or sorry, adding the probabilities together is, multiplying the probabilities together for an AND gate is not going to give you the correct answer.

So note one to the entry says two events A and B are dependent. If the probability of occurrence of A and B, the probability of A and B is greater than PA times PB. Okay, there’s some relationship between them that’s driving the probability of failure up. Note two to the entry says C 9.4.2 and IEC 61511 part 3, Annex J for consideration of dependent failures between protection layers.

Note three says dependent failures include common cause. So common cause is a dependent failure because a single stressor causes both devices to fail at the same time for the same reason. And when we look at note two, there’s going to be a discussion of the fact that two events may contain common hardware that makes them not independent of each other that creates a common failure.

So to really understand dependent failures between multiple independent protection layers, I’m going to point you toward a, uh, a Kenexis, uh, another Kenexis podcast, or if you just want to go to the website and look up our webinars, there is a webinar that I did that talked about using fault tree analysis.

When you have common components that are shared between multiple independent protection layers, and it helps you understand how to do the math correctly because fault tree can do this kind of stuff rigorously, especially if you’re using a sophisticated fault tree tool like Kenexis is Arbor software, uh, to be able to understand that. So, uh, in the example that I gave, I was using two level transmitters, but those two level transmitters were part of the initiating event. They were also part of an alarm IPL, and they will also part of the safety instrumented system.

But if both of those devices fail, you get an initiating event and you lose all your protection layers. So, uh, just doing your straight up LOPA is not going to address that issue. You’re going to need a more sophisticated tool to be able to analyze the situation like fault tree analysis. Okay.

Detected, Revealed, and Overt Failures

Following up on clause 3.211, we have definitions, uh, definition 3.2.13 that is also going to talk about a subset of failures. So, uh, clause 3.2.13 has three definitions or three different ways of saying essentially the same thing. So technically this one definition is for the word detected, the word revealed, and the world word overt. And you know, we have a lot of situations where we use multiple different words to describe the same concept. That’s what we’re looking at here.

So the definition says relating to hardware and software failures are faults, which are not hidden because they announce themselves or are discovered through normal operation or through dedicated detection methods, i.e. diagnostics. Okay.

Before I go into the definition a little bit further, I’m going to go ahead and just hit you with like a half page of notes to this definition. All right. Note one to the entry.

There are some differences in the use of those three terms. Overt is used for failures or faults, which announce themselves when they occur due to a change in state. Uh, the repair of such failures can begin as soon as they’ve occurred. So an overt failure of a valve, uh, that causes the valve to slam shut. It just announced itself. Your process went crazy haywire because the valve that’s supposed to be open went closed. There’s no way to unsee this. Uh, it’s like a pump stopping is not something that can hide. It is overt.

You know about it right away because everything just went crazy in your process.

Detected on the other hand is for failures that do not announce themselves when they occur and which remain hidden until detected by some means. For example, diagnostic tests, proof tests, operator intervention, like physical inspection and manual tests. The repair of such failures can begin only after they have been revealed. See note two for the specific use of this term in IEC 61511.

All right. So detected failures are failures that you wouldn’t know about if you didn’t do a diagnostic test. So if a valve starts to get the stiction failure mode, so it sits in the position for a long period of time to where it would get stuck. And if you tried to move it, it wouldn’t move. Well, if you do a partial stroke test, so you kind of stroke the valve a little bit and then bring it back to its original position just to make sure that it’s moving, you can detect that that failure actually occurred.

So partial stroke testing is an example of diagnostics that you would perform on a valve. And yeah, so that’s a failure that, you know, once it happens, you know that it’s there and you can start repairing it, but it didn’t announce itself. You had to actually do a diagnostic test to see that it was there.

And finally, the third part of note one is revealed is used for failures or faults that become evident due to being overt or as the result of being detected. So kind of overt and detected are kind of different. Revealed is kind of generic. Either way, it was overt or it was detected. Now it is revealed that the failure is present and I can go do something about it.

All right. Note two to the entry. IEC 61511. And in IEC 61511 and except when the context suggests another meaning, the term dangerous detected failures or faults is related to dangerous failures detected by diagnostic faults. Ha ha. So when we’re talking about dangerous detected failures, what we’re really looking at is failures that would inhibit, prevent the safety system from working. So it’s a good thing we already had the definition for dangerous failures. And it’s those dangerous failures that are detected through the diagnostic testing.

So if you detect that a valve is stuck because of partial stroke test, that is a dangerous detected failure.

Okay. Note three. When the detection is very fast, for example, by diagnostic tests, then the detected failures or faults can be considered to be overt failures or faults. So, okay. So an overt failure, again, we went to all the trouble of differentiating between an overt failure and a detected failure. And we have note three coming in and muddying up the situation again saying, well, they’re exactly the same.

Um, in reality, uh, this note being aside and overt failure, people mean something that announces itself as opposed to a, a diagnostic test. It’s very rare in conversation of SIS design that you would say, oh, that, that’s an overt failure because it was detected by the diagnostic. So, uh, try not to get too dogmatic about it and think about what you’re doing, the context of where you’re using this term to, to really understand what they actually mean. Okay.

Um, and then kind of the second part of note three, when the detection is not very fast, the detected failures or faults cannot be considered to be overt failures or faults when addressing safety integrity levels.

Okay, great. Note four, a dangerous revealed failure can only be treated as a safe failure if effective measures, automatic or manual, are taken in a short enough time to maintain process safety.

I’m going to have a very long discussion when we get to clause 11.4 about the, about diagnostics, about diagnostic coverage and about safe failure fraction. And some of the, shall we say, dirty pool that some of the equipment vendors are engaged in, uh, when publishing safe failure fractions and diagnostic coverages, which yield to safety integrity levels. Um, there’s just kind of giving you a little bit of a tease into what’s going to happen.

Um, safe failure fraction that we use to make decisions about design is not just what percentage of the time the safety instrumented system fails safe, but it’s also includes, uh, the dangerous detected failures because there’s an assumption that if you can detect a dangerous failure, you can convert it to a safe failure by shutting down your plant, but it doesn’t require you to do that. So that’s kind of, uh, there’s some subjectivity in there and it requires a much longer discussion that you are going to get when we get into clause 11.4. Okay.

Devices and Field Devices

Continuing on 3.2.14 is device. And the definition of device is hardware with or without software. Capable of performing a specified function. So we’re defining device. It’s definition, not super different from component. What’s the difference between a component and the device? Good question. They don’t get into detail on that. And, and the two terms are kind of used interchangeably, but it is something that you’re going to run into note one to the entry examples of devices are sensors, logic solvers, final elements, operator interfaces, and field wiring.

So devices components are things that subsystems and SIFs are built out of, uh, kind of a subset to that definition.

Because as I mentioned last time, we are in quasi alphabetical order. We go from device to field device 3.2.14. The definition of field device is an SIS or BPCS device connected directly to the process or located in close proximity to the process. Uh, note one, uh, to the entry examples are sensors, final elements, and manual switches, manual switches. Manual switches, people generally want to leave in the control room. Now, sometimes they’re out in the field. So this, I don’t really think it needs a definition unless maybe you’re an academic who’s never actually been out to a process plant.

And there are a lot of those that sit in the committee meetings. Um, so, uh, field device basically means it’s out in the process. And we’re differentiating between field devices and control room devices. So usually let’s say back in the olden days, um, your control room would have the controllers, the PLCs, your input cards, output cards would be in marshaling racks that are right there next to the control room. And the control room is located some distance away from the process that contains the reactors, the heat exchangers, the piping, and so on.

So anything that’s out there in the field right next to the process is going to be a field device. Whereas the other stuff is going to be a control room device.

Now, uh, in the past decade, maybe two decades, things have gotten a little bit muddled because, uh, in order to make design of process plants more efficient, we’ll generally do all of our marshaling out close to the field, uh, in something called often called a remote instrument enclosure. So, uh, you’ll kind of build a trailer, uh, that you can literally roll out next to the plant that contains all of the hardware, uh, in terms of IO cards, CPUs for safety instrumented systems and control systems.

And then you’re going to run, uh, one or redundant fiber optic cables from your remote instrument enclosure, um, all the way back to your control room, which these days could be a half mile, a mile, more than a mile away from the process to basically reduce risk of accidents in the process impacting, uh, the operators.

So, uh, again, we have definitions, but you really need to think about the context of what you’re looking at when you’re making decisions about things, because normally you would think that a PLC would be a control room device and not a field device. Yet a lot of times they’re mounted in boxes next to the process. So, uh, traditionally we would think about sensors and final elements, things that are actually touching wet by the process chemicals. Uh, and that proximity thing is more of a secondary. Again, always consider the context of what you’re doing and who you’re talking to.

Diagnostics and Diagnostic Coverage

3.2.15 is diagnostics. We’ve already started talking about diagnostics when we talked about, uh, overt failures, detected failures, and dangerous failures. Diagnostics, the definition is frequent in relation to the process safety time, automatic tests to reveal faults. So very high speed tests that are being done generally automatically. That kind of is, is kind of a sore point between a few people, uh, that are going to reveal us generally a subset of all the failures that can happen.

So, um, frequent. So if you’re looking at a smart sensor or a safety PLC, these diagnostic tests are happening like every scan, a hundred milliseconds, 300 milliseconds, even something like a partial stroke test can be a diagnostic because it can be done automatically. Um, but those might be happening once a week or once a month, but it’s still very frequent in relation to the full total manual proof test of the safety instrumented function as a whole or of a component or a subsystem as a whole.

Um, another thing or the second, uh, well, I’m going to get to diagnostic coverage in just a second because that’s, that’s part of the definition, but, but diagnostics, um, where things get a little bit tricky with diagnostics and, and people will fight and disagree is manual tests. So different people have had different interpretations, you know, obviously your equipment vendors are going to say it has to be automatic because well, then you have to buy it from them. Uh, but other people will argue that very frequent, um, manual tests can also be diagnostic.

So let’s go back to that example of, of the partial stroke test. If you do a partial stroke test once a week and it’s done by a smart positioner, like a DVC, uh, 6,000 from Fisher, for instance, is an example of a smart positioner that’s capable of doing automatic diagnostics. Um, and that test happens once a week. Okay. It’s automatic. You should be able to take credit for it when you’re running your SIL calculations.

Well, what if instead of using a smart positioner, if instead I went up to the valve and I put a jammer in to prevent a sliding stem valve from sliding all the way closed. So it’s only going to be able to slide part of the way onto the jamming device. So I put in the jamming device and I disconnect the wires and I see that the valve fell immediately on top of the jamming device. When I plug the wires back in, it immediately shoots back to the fully open position. And I do that test at the same frequency as the smart positioner is automatically doing the test. Why can’t I take credit for it?

Even though it’s done manually, it’s happening at exactly the same frequency.

So this is an area where you have a definition that contains that word automatic. Uh, but even the certification agencies in some cases will allow that test to be done manually. And well, what if I need to manually trigger the automatic test? Does that run a foul? So this definition seems pretty straightforward, but there is a little bit of politicking, a little bit of arguing in the background over what it actually means. My personal opinion is I don’t care whether it’s automatic or, um, manual, uh, as long as it is performed at a high frequency in comparison to the manual proof test.

I will allow it to be credited as a diagnostic when SIL verification calculations are being performed.

All right. 3215 is a 3215.1 subset of diagnostics is diagnostic coverage, uh, which comes with the acronym DC for diagnostic coverage. Um, uh, in reality, um, if you look at the ISA training classes and a lot of other references, uh, that is going to be C subscript D, uh, coverage diagnostic as opposed to C subscript M coverage manual. Always, uh, be careful where you’re at and what you’re looking at in terms of these definitions. A lot of times, a lot of different acronyms are going to apply, which is the truth in this case.

So diagnostic coverage is a number that we’re going to use to use, uh, to do, uh, to do our SIL verification calculations. The full precise definition is fraction of dangerous failure rates detected by diagnostics.

Diagnostic coverage does not include faults detected by proof tests. So what percentage of the overall dangerous failure rate can you detect with the diagnostics? It’s a percentage, uh, note one to the entry diagnostic coverage is typically applied to SIS devices or subsystems. For example, the diagnostic coverage is typically determined for a sensor or a final element or a logic solver. It’s not determined for the SIF as a whole. That would be completely meaningless.

Note two to the entry. For safety applications. The diagnostics coverage is typically applied to dangerous failures of SIS devices or SIS subsystems. For example, the diagnosed for the dangerous failures of a device is, oh, here we have a, uh, an equation I would love to be able to show you, but DC equals lambda DD divided by lambda DT, where lambda DD is the dangerous detected failure rate and lambda DT is the total dangerous failure rate for an SIS subsystem, uh, with eternal redundant internal redundancy. DC is time dependent. Um, so lambda DT at DD at time T over lambda DT at time T.

So, wow, the academics really got in there with that last sentence about time dependency, uh, of the, uh, diagnostics because diagnostics aren’t continuous. They happen at different points in time. Note three to the entry, uh, again, uh, and let me tell you, we have no shortage of academics who are really going into the nitty gritty details of the calculate, how the calculations are performed often in my opinion, to the detriment of the standard, just kind of going into way too much mathematical precision, considering, uh, the degree of error that’s baked into all of our failure rates.

But I digress.

Uh, note three says when the diagnostic coverage and the total dangerous failure rate are given, the detected lambda DD and undetected lambda DU dangerous failure rates can be computed as follows. So lambda DD is the diagnostic coverage multiplied by lambda DT, the total, and lambda DU is one minus DC times lambda DT.

Now, lambda DT is what you’ll see in the standard, um, in the ISA training and the ISA technical reports. We’re generally just going to use lambda D and you won’t see that T in there because lambda D is a starting point. So we start with a total failure rate. We’re going to split that into lambda S for safe, lambda D for dangerous. And then we’re going to split lambda D into lambda DD for those portion that’s detected. And lambda DU for the portion that is not detected.

So the difference between the portion that’s detected and not detected is that fraction, the DC or C sub D the diagnostic coverage or what percentage of all of the dangerous failures can be detected by those high speed automatic generally diagnostics. All right.

Diversity and Redundancy Design

One last definition. Um, before we, uh, wrap it up for the day, 3.2.16 is diversity, diversity. The definition is different means of performing a required function, not a particularly helpful definition. Um, note one to the entry says diversity may be achieved by different physical means, different programming techniques, or different design approaches. So when we say diversity, we’re going to do the same thing different ways. Uh, and this is going to get even more broken down into identical redundancy and diverse redundancy.

Uh, so yeah, to get diversity, first off, you need to have redundancy. And each of your redundant components needs to do things different ways. So for instance, if I need to stop flow going out to a tank truck that I’m filling, because it’s about to be overfilled, I can have two valves that are the same make and model.

That’s identical redundancy. That’s truly identical redundancy. I can have two valves that come from different manufacturers. I’m still going to call that identical redundancy because you’re using the same type of equipment. Uh, let’s say you have two block valves, even though they’re from different vendors, they’re going to have a lot of the same failure modes. Now, maybe you can use one ball valve and one gate valve.

That’s going to provide you a little bit more diversity or the ultimate in diversity is I can have one block valve and I can stop the pump. So those are completely diverse, different, uh, methods of accomplishing the same objective that are going to have a minimum of common modes of failure, which is going to decrease your beta factor and decrease the probability that common cause failures occur.

So when we’re trying to decrease common cause failures, the key factor that we’re going to be looking at is diversity. So with that, that’s going to wrap us up for this week’s installment.

Vertigo Software and Episode Close

Next week, we’ll pick it back up again at 3.2.17, where we’re talking about the definition for error.

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. Thank you.