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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E19 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 19: IEC 61511, Clause 9.1 through 9.2.4 (Allocation of Safety Functions to Protection Layers)

—

## Episode Teaser and Introduction

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

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

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

## Clause 8 vs Clause 9 Gap and Closure

So, clause 8 was process hazard and risk assessment. And the hazard and risk assessment, as it's described in the IEC 61511 standard, doesn't go into the details of what do you do about the risk. So, really to pick a SIL target, picking a SIL target is an exercise in risk analysis. You need to determine the risk of the process without the safety instrumented function and then determine how much safety instrumented function do you need. What is its probability of failure? How good does that set of equipment need to be in order to make risk tolerable?

Well, in the standard, they broke that into clauses 8 and clauses 9. So, clause 8 is process hazard and risk analysis. And then clause 9 is allocation. So, the full title of clause 9 is allocation of safety functions to protection layers. So, the way to think about this is that clause 8 determines what the gap is and clause 9 closes the gap.

But anyone that's ever been in a SIL selection session, anyone that's been in a layer of protection analysis, knows that these two activities are going to occur at the same time, in the same room, with the same group of people. Now, some companies, some organizations extend the allocation part of things with something that they will call a rationalization.

And that's where the rationalization, for those of you who do it, is to look at all of the scenarios that utilize a single safety instrumented function or a single safeguard of any kind in reality. And make sure that the SIL target and the design of the safety instrumented function is appropriate not just for the one scenario that you're looking at, but in total for all of the scenarios.

So, if you're using OpenPHA, Kenexis OpenPHA, to do your hazard and risk analysis and your allocation, when you're doing a rationalization study, what you're going to do is you're going to open up the Safeguards tab and you're going to find your safety instrumented function. And then that safety instrumented function is going to, there's going to be a list of all the scenarios in which that safety instrumented function is used. And you can go ahead and address them one at a time. Make sure all the attributes of an independent protection layer are appropriate for all those scenarios.

But, again, conceptually speaking, when you're doing the layer of protection analysis, you're usually going to walk out of the room at least with a SIL target for that scenario if you don't end up with the SIL target overall.

## Clause 8 Scope and BPCS Initiating Event Limit

Now, the way that the Standards Committee broke things down is kind of necessary for kind of spilling out requirements. So, whereas Clause 8 is very short, Clause 9 is going to be a little bit longer. And the reason that Clause 8 is short, even though the topic is very complex, is that most of hazard and risk analysis is outside the scope of expertise of instrumentation and control engineers. The IEC, after all, is the International Electrotechnical Commission. Electrotechnical, this is instrumentation and control people.

What, you know, what right do they have to make rules about how to do a hazard and risk analysis? That is an activity that's generally under the purview of more process engineering, process safety.

So, when you look at Clause 8, you're generally looking at the requirements that the instrumentation and control group needs from the PHA. So, you can kind of think of it as the instrumentation and control people telling the PSM group what they need their hazard and risk analysis to yield so that we, the instrumentation and control community, can do our job and design those safety instrumented functions. So, you know, a lot of the detail for Clause 8 is kind of unspoken other than, after you're done, this is the information that we're going to need.

And the only thing that is really a hard requirement coming out of that is the limitation on the dangerous failure rate of a basic process control system being an initiating source for a scenario because that is, again, under the purview of instrumentation and control. And it kind of, we want to make sure that the PSM group doesn't step all over the definitions of what SIL 1 is by assuming that they have a SIL 1 or SIL 2 safety critical controller but not mentioning that, not documenting it as such and kind of letting that fly under the radar.

So with Clause 8, we're basically saying that we analyze the risk. What are the causes of the hazardous scenarios? What are the consequences of the hazardous scenarios? And that is going to lead to something that we sometimes refer to, you know, definitely in my SIL selection book, I refer to something called the inherent risk. We'll risk just based on the design and operation of the plant, ignoring the beneficial impact of any of the safeguards.

So once we know what the risk is ignoring all of the safeguards, then we can start figuring out what safeguards we need and how much credit can we take for them. So we need to strip all the safeguards away so that we can do a formal rigorous assessment of what safeguards are we taking credit for and how much credit are we taking for those safeguards. And that's going to be true whether the safeguard is a safety instrumented function or not.

## Clause 9 Purpose and Clause 9.1 Objectives

Okay? So that's the purpose of Clause 9. So once again, the title of Clause 9 is Allocation of Safety Functions to Protection Layers. So in Clause 8, we did a hazard and risk analysis to figure out what the inherent risk of the plant is and what the gap between the inherent risk and the tolerable risk is. Now in Clause 9, we are going to close the gap by assigning different safety functions to have supply different amounts of risk reduction in order to achieve tolerable risk. And again, looking at the title, it says allocation of safety functions to protection layers.

Not safety instrumented functions, but safety functions. Anything that reduces risk. And one of the critical safety functions is going to be the safety instrumented function.

Okay, so if we look at Clause 9.1, 9.1 is objectives. It states the objectives of the requirements of Clause 9 are two, and then it provides three bullet points and two notes. Those bullet points, number one, allocate safety functions to protection layers. Okay, so bullet point one says our objective is to assign physical equipment or administrative controls to the protection layers that were credited while we're doing this process. Number two, determine the required CIFs. So you have a big collection of all of the safety functions.

And if you're working in OpenPHA, there's going to be a safeguard tab where you can show the IPLs, the independent protection layers. That's the total list of safety functions. Then you need to determine which of those are going to be implemented in a safety instrumented system, making them CIFs. The third item is to determine for each SIF the associated safety integrity requirements. All right, very long-winded way of saying I need to figure out what my safety functions are and I need to assign a CIL target to them.

Actually, it's not that much more long-winded, but same thing, stated a little bit differently.

All right, for Clause 9.1, we do have two notes. Note one says, account can be taken during the process of allocation of other industry standards or codes. What does that mean? Okay, when you're doing your allocation, you're not starting with a blank sheet of paper. There are other codes like API 556, API 616 through 619, NFPA 85 that are going to tell you what safety instrumented functions are expected to be supplied in this application, regardless of any risk analysis that you might do.

So understand what standards and codes are going to be applicable to your safety instrumented functions to the process under control, and make sure that those are allocated appropriately, regardless of your hazard and risk analysis or your LOPA. If NFPA says you need a high fuel gas pressure trip, it doesn't matter that it's not physically possible for your fuel gas pressure to go high. Some people are in that situation. You need to supply it anyway because that's what the applicable industry code and or standards said.

So definitely, before you go in to your allocation process, even before you go into your hazard and risk analysis process, you're going to need to look at what are all the codes and standards that are applicable to your equipment under control and make sure that those safety instrumented functions are represented in the analysis and show up in the design, regardless of what your HAZOP and LOPA said were required. Note number two states the integrity requirement for each SIF might include associated risk reduction, PFD, PFH, or SIL.

So there are a lot of different metrics that define how much risk reduction or how effective a safety instrumented function needs to be. The note is saying that, well, you know, it could be more than just SIL 1, SIL 2, or SIL 3, depending on the mode of operation, depending on the precision levels that you perform while you're doing your risk analysis. So the performance targets could be a larger amount of things than just a numerical SIL.

## Clause 9.2 Allocation Requirements and 9.2.1

Okay, that moves us along into Clause 9.2. Clause 9.2 is the requirements of the allocation process. So, we just finished our hazard and risk assessment. We know the inherent risk of the plant. We know the tolerable risk of a scenario. We know that we have a gap. So we need to close the gap and Clause 9.2 is going to present a bunch of rules that we need to follow when we… So let's start with the first one. Clause 9.2.1 states, the allocation process shall result in… And then you have two bullet points in our note.

Bullet point number one, the allocation process shall result in the allocation of safety functions required to achieve the necessary risk reduction to specific protection layers. So we're going to take all those IPL credits for different independent protection layers and list out what those protection layers are and how much credit we are assigning to them. So a list of protection layers and a list of necessary risk reduction for each protection layer.

Again, that's something that you would do in the safeguards tab while you're working in Open PHA. bullet point number two states, the allocation process shall result in the allocation of risk reduction or average frequency of dangerous failure to each SIF. So we're allocating… So it's kind of a subset of bullet point number one, basically saying, okay, we have safety functions, we're assigning risk reduction to those safety functions, but we're also assigning SIL targets. We're assigning risk reduction to safety instrumented functions specifically.

Now, this clause actually gets a little bit tricky. And this is something right now. So I'm recording this on November 25th in 2024. Last week, I was in Houston at the IEC 61511 committees and in the next version of the standard, we're going to tighten up on this clause a little bit. Because assignment of dangerous failure rate to a safety instrumented function, what does that mean? That means that we have a continuous demand mode safety function. And when you have a continuous demand mode safety function, allocating risk reduction to it actually doesn't make sense.

Continuous mode safety functions, basically the way that they operate is that when they fail, they are the initiating event. So failure of this critical control loop is the initiating event that's going to result in a consequence. So if you have a continuous mode safety function, you actually needed to define its dangerous failure back in clause 8 because it's not a protection layer, it's an initiating event at the end of the day. So there's some subtlety around how continuous mode safety instrumented functions need to be treated. And the way the clause 9.2.1 is written is a little bit clunky.

I mean, it gets to the point that all safety instrumented functions need to have their performance targets assigned to them, but it's kind of strange to do it in the allocation phase because, well, it's an initiating event and that kind of loops you back to clause 8.

Honestly, personally, I don't care whether you think about it in clause 8, think about it in clause 9 because as I mentioned earlier, most of the activity that's occurring in clause 9 is happening all at one time in one meeting when we're analyzing risk and picking the SIL targets. So those are the requirements of the, or those are the things that the allocation process shall result in, which is basically a list of safeguards and maybe continuous mode safety functions, and what their risk reduction targets are. How well are they to perform?

What design do you need to have in terms of the risk reduction achieved? Now, there is a note to clause 9.2.1. The note states, legislative requirements or other industry codes may influence the allocation process. So, I just kind of beat this up a little bit in clause 9.1. The fact that there are industry codes, there are industry standards that are going to tell you what safety instrumented functions you need. And a lot of times they tell you a lot about how those safeguards, how those safety instrumented functions need to be designed. You can't ignore that.

The IEC 61511 standard is not a replacement for other sector-specific standards like NFPA 85. It's a supplement. Those two standards, all of these standards, need to work together. They shouldn't conflict with each other. You should be able to be compliant with all these standards simultaneously. So, if NFPA 85 tells you you need a safety function, you need to put it in regardless of whether or not your IEC 61511 risk analysis tells you that you don't need it.

## Clause 9.2.2 SIL Derivation from PFD

All right. Next clause up is 9.2.2. Clause 9.2.2 states the required SIL shall be derived taking into account the required PFD or PFH that is to be provided by the SIF. Okay. So, that's the requirement. There is a note that says further guidance can be found in IEC 61511 part 3. And remember part 3 is that portion of the standard that talks about safety integrity level selection techniques. All right. So, clause 9.2.2. The required SIL shall be derived taking into account the required PFD that is to be provided by the SIF. I mean, that's just obvious, isn't it?

I mean, when you have a gap between the tolerable frequency and the estimated frequency of inherent risk, there's a PFD that's going to allow that mitigated event likelihood to be less than or equal to the target. And that's what needs to be provided to the protection layers with the safety instrumented function being one of them. So, yes, your SIL or your allocation in general needs to be such that you achieve your performance target.

Now,

PFH, again, is a little bit tricky. It's something that we're going to clean up in the next version of the standard. Because, again, if you're in continuous mode, we were looking at that initiating event frequency back over in the clause 8, in the determination of the inherent risk. So, it is a bit of a circular process. I'm not going to get too dogmatic about it, but ultimately, when you have a continuous mode safety function, it's an initiating event. It doesn't provide risk reduction per se. It basically, its performance can determine how frequently you will have an initiating event.

## Clauses 9.2.3 and 9.2.4 SIL Table Selection

Okay, next item up is clause 9.2.3. 9.2.3 and 9.2.4 are the SIL table clauses. They are the clauses that define what a safety integrity level is in conformance with a variety of different metrics. So, that table that says SIL 1 is this, SIL 2 is that. That's going to be table 4 in the demand mode of operation, table 5 in the continuous high demand mode of operation where you're looking at frequency instead of probability of failure. So, let's look at the specific text. Clause 9.2.3 states that for each SIF that's operating in demand mode, low demand mode is the most appropriate thing.

High demand mode is a very tricky item because in high demand mode, your ability to take credit for testing is sketchy at best. And treating your performance metric as a probability is probably not mathematically correct. So, generally, we're going to want to switch over to frequencies even when we're in high demand mode, but that's something that, well, let's say we in the standards committee are tightening up on this a little bit for the next version of the standard.

Regardless, it says 9.2.3 is going to say that you're going to want to either define your safety function in terms of PFD, probability of failure on demand, and that's where you're going to look at table 4, or in the high demand mode of operation, you might want to look at table 5, which defines the safety integrity levels in terms of frequencies. And then for clause 9.2.4, it says if you're in the continuous mode, you want to use table 5 for sure, again, with table 5 being the table that defines SIL targets in terms of frequencies.

Okay, so then kind of scrolling down in the section or clause 9.2.4 specifically, there are going to be two tables, and then there are going to be three notes associated with the tables.

So let's get into those.

## Table 4 Demand Mode SIL Definitions

Table 4 is the OG table. It's the original. It was used by the ISA committee all the way back when I joined up in 1994 and when we released the first technical safety, functional safety standard in 1996. We had a table that related safety integrity level to probability of failure of the safety instrumented function. Now, it turns out that thinking about a safety instrumented function in terms of probability of failure is only appropriate if the challenges to the safety instrumented system are infrequent in comparison to how often you test the safety instrumented function.

So, we want it to be more likely, much more likely, that you detect a failure through testing than through an actual demand on the system. And mathematically speaking, if that's not true, your math kind of falls apart. And you should be looking at the frequency of failure of the safety system going over to table five. So, again, table four defines SIL targets in terms of probability of failure on demand and is appropriate for the demand mode of operation, specifically low demand mode. High demand mode is this kind of sketchy middle ground. Some people apply it.

Some people switch to frequency for high demand mode. Ultimately, if you're on the edge, it's an analysis of how often do you challenge versus how often do you test. Okay, going into the details, table four defines four safety integrity levels. And these four safety integrity levels are named, are you ready for this? SIL one, SIL two, SIL three, and SIL four. Okay, pretty obvious, four levels. As the SIL levels increase, the performance, the integrity, the effectiveness of the safety instrumented system increases, and it does so by orders of magnitude.

So, not by accident, a safety integrity level tells you how many orders of magnitude of risk reduction that a safety instrumented function is going to supply.

Now, back in the day in 1996, the ISA 84 committee did not define a safety integrity level four. We stopped at a safety integrity level three because we realize it's borderline impossible to design to a SIL four, and we kind of question the rationality and judgment of anyone who is going to put that much faith and credit in one automated system to be able to reduce your risk to a tolerable level. That said, the IEC 61508 standard, which came out in 1998, two full years after the ISA 84 standard, and then the IEC 61511 standard, which first came out in 2003, acknowledged SIL four.

But as we're going to learn next week, warns you up and down, backwards and forwards never to design to SIL four. So next week is going to be the discussion of why you never designed a SIL four, clauses 925, 926, and 927 in the standard. Okay, but I digress. So we have a road number one is SIL 1234, or I'm sorry, column number one, and then there are two more columns in table four. The second column talks about probability of failure on demand, so what PFD is associated with the SIL, and then the third column over correlates SIL to risk reduction factor.

And risk reduction factor is a number that is meant for human beings, whereas PFD is a number that's more appropriate for robots and computers. I think everyone has run into the situation where they say, okay, is 9.9 E-3 greater than 1.0 E-2, and you kind of have to scratch your head a little bit and think real hard, especially as you get older. That scientific notation is kind of rough, whereas the risk reduction factor, the way we use it is 1 over the PFD average. Now, conceptually speaking, a risk reduction factor tells you how many times risk is reduced.

So, a risk reduction factor of 10 means risk is reduced 10 times. A risk reduction factor of 100 means risk is reduced 100 times. But I will caution you, this is only true for preventive safety functions. So, now, you might have a mitigative safety function like you detect a fire and use a fire detector to put the fire out. Well, if that safety instrumented function works, there's still a consequence that occurs before the safety instrumented function activates.

And that kind of what is the risk that is there even if the safety function operates properly, that totally screws up the whole concept of risk reduction. So, in reality, risk reduction is only appropriate to think about and talk about as 1 over PFD if it is a preventive function. If it's a mitigated function, the actual risk reduction is not 1 over PFD. That being said, 99 times out of 100, when someone says risk reduction factor, they don't mean the number of times that risk is reduced. They simply mean 1 over PFD. So, be careful about how you use that risk reduction factor.

Think about what the person you're communicating with, what context they're speaking in, because for mitigated safety functions, in reality, risk reduction is not 1 over PFD.

## SIL Boundary Clarification and RRF Nuances

Okay, so, table 4, we define these functions. SIL 1, in terms of PFD, is between 10 to the minus 1 and 10 to the minus 2, or 0.1 and 0.01. Now, what's really important to understand is that that 0.1 is not included in SIL 1. And this is some clarification that happened in 2016. And the clarification helped fix one problem but created more problems. Okay, so, SIL 1 is between 0.1 and 0.01. 0.01 is technically included in SIL 1. 0.1 is not.

Now, if we, and kind of another easier way to think about that, this, is in terms of percentages. So, SIL 1 is, it's going to fail somewhere between 10% and 1% of the time when it's challenged. Looking at risk reduction factor, we invert the PFDs. So, when we invert 10 to the minus 1, we get 10. When we invert 10 to the minus 2, we get 100. So, the risk reduction factor associated with SIL 1 is between 10 and 100. But, the very strict definition states that 10 is not included in SIL 1, but 100 is. Why? Why did we do this?

Well, we wanted to make it clear that a basic process control system interlock can achieve a risk reduction factor of exactly 10, not even a little tiny skosh higher, exactly 10, and that is not SIL 1. Very often, we take credit for a lot of SKAI, SKAI, S-C-A-I, safety control alarms and interlocks and give them a 0.1 PFD, but we are not assigning a safety integrity level of 1 to those.

So, the clarification that says 10, right on the nose is not SIL 1, was done to make it clear that we can assume one order of magnitude of risk reduction coming from SKAI, safety controls, alarms, and interlocks that are not SIL rated safety instrumented functions.

Okay, so 10 is not in, but 100 is.

so we fixed one problem and we just created another problem because now we have people going, oh, if we, if the risk reduction factor is 100, that's just SIL 1. no. Well, technically, yes, but if you run a LOPA and you need to achieve a risk reduction factor of 100, you need to achieve a risk reduction factor of 100 and no SIL 1 quality design is going to get you to a risk reduction factor of 100. So even though technically speaking, a SIL 1 safety function can end at 100, if you calculate that you need 100, no self-respecting expert in safety instrumented systems is going to call a risk reduction factor of 100 SIL 1.

Everyone is going to call it SIL 2. So if your LOPA results in a risk reduction factor of 10 for a safety instrumented function, meaning something that is built into the safety instrumented system, that safety logic solver, please don't say that it's not SIL rated. It is a SIL 1. If you end up with a risk reduction factor of 100, never call it SIL 1. Always call it SIL 2. So if you have a function that is sitting in the SIS logic solver and you're at the edge, always go to the more conservative.

So a risk reduction factor of 10 for something in the SIS logic solver, please treat it like SIL 1. A risk reduction factor of 100, please treat it like SIL 2, and so on.

Okay, so that was the definition of SIL 1. SIL 2 is an order of magnitude better. So its probability of failure is going to be between 1% and 0.1%. SIL 3 is an order of magnitude better than that. Between 0.1% and 0.01%, SIL 4 an order of magnitude better than that. In terms of risk reduction factors, SIL 1 was 10 to 100. SIL 2 an order of magnitude better at 100 to 1,000. SIL 3, 1,000 to 10,000. And then SIL 4 is going to be greater than 10,000. And that's just in terms of the pure probability of failure on demand.

There are other attributes that we will get into in clause 11 that go beyond just the PFD or the risk reduction factor, but wait for it until we get to clause 11 when we start bringing in hardware fault tolerance and other aspects of the design beyond just the PFD.

Okay, so most of the time, greater than 99% of the time in my experience in the chemical process industries, we're going to pick our SIL targets based on table 4. number 4. But there are the oddball safety critical controls and high frequency high demand mode functions where the challenges to the safety system are coming so frequently that it makes no sense to talk about PFD of the safety instrumented function. We must instead logically look at the failure rate of the safety function.

## Table 5 Frequency-Based SIL Targets

This is in table 5 and table 5 also has the first column of SILs that are SIL 1, SIL 2, SIL 3, and SIL 4. But instead of PFDs, there are ranges of failure frequency. So SIL 1 fails at 1 times 10 to the minus 5 to 1 times 10 to the minus 6. And again, that 1 times 10 to the minus 5 is not included. It must be greater than 10 to the minus 5. But 1 times 10 to the minus 6 is included in SIL 1.

So kind of looking at that number, if you remember, there are 8760 hours in a year. So let's kind of round that up and say 10,000 hours in a year would be 10 to the minus 4-ish hours in a year. So if you look at the failure frequency in terms of years, it's going to be somewhere between once in 10 years to once in 100 years is the failure rate of SIL 1. That's actually quite hard to achieve when you think about it. SIL 2 is going to be roughly once in 100 years to once in 1,000 years, but I'm going to move out of years.

I was just kind of doing that to make it a little bit more tangible for the human mind because these things are defined in the standard in hours. So SIL 2 is 10 to the minus 6 to 10 to the minus 7 failures per hour. SIL 3 is 10 to the minus 7 to 10 to the minus 8. And SIL 4 is 10 to the minus 8 to 10 to the minus 9. So table 5, high demand mode safety functions, safety critical controls, continuous mode safety functions is what you're going to use to that's what you're going to use table 5 to design.

## Notes on the SIL Tables

Now before I close out this session, let's talk about the notes on the SIL tables, table 4 and table 5. Note 1 states, further explanation of modes of operation can be found in 3.2.39. We already talked about this, go back a few weeks ago when we were in definitions and I will describe for you in excruciating detail the difference between high demand mode, low demand mode, and continuous mode. That's in clause 3.2.39 in definitions.

Note 2, the SIL is defined numerically so as to provide an objective measure for comparison of alternative designs and solutions. However, it is recognized that given the current state of knowledge, many systematic causes of failure can only be assessed qualitatively. A few weeks from now, we're going to get to clause 11.9 that talks about SIL verification calculations. And when we talk about that, I am going to beat to death the concept of random hardware failures and why looking at human failures when you're calculating SILs is counterproductive. It's worse than a waste of time.

It's actually going to lead you to make bad design decisions. So, there is a random failure aspect that we're looking at in tables 4 and 5, but this standard also has a lot of qualitative aspects, cookbook aspects, for how to design your safety instrumented system to address systematic failures, human failures.

Note 3, the required average frequency of dangerous failures for a continuous mode SIF is determined by considering the risk caused by failure of the continuous SIF mode together with the failures of other devices that lead to the same risk, taking into consideration a risk reduction provided by other protection layers. Okay, risk analysis of a continuous safety mode function is complex.

So, we're basically saying, okay, there's scenarios where failure of the controller is an initiating event, and we need to look at this in the context of everything else going on in the scenario in order to assign a SIL target to a continuous mode safety function.

Assignment of SIL targets to continuous mode safety functions is a very complex analysis. We at Kenexis will usually do it using a focused QRA, using fault tree analysis inside the Kenexis Arbor fault tree analysis tool. You know what? That might be a great topic for another webinar. All right, note to self, Ed, do a webinar on calculating the SIL target of a continuous mode safety function to flesh out note three even a little bit more.

## Wrap-Up and Next Episode Preview

All right, so with that, we've been going at it for about three quarters of an hour now, so I'm just going to go ahead and break for this week, let you absorb this information before we get into next week. So we have only gotten to clause 9.2.4. There is still a lot more going in on in clause nine. Clause nine, the allocation clause.

Next week, it's probably going to be a discussion a little bit on the shorter side because I'm only going to go through the balance of clause 9.2. Specifically, it's going to be a master class in why you don't pick SIL 4 because there is a lot of text, there's a lot of ink spilled in the 6, 15, 11 standard related to why you shouldn't pick SIL 4 and what you should do if your first pass risk analysis tells you that you have SIL 4. But I'm not going to talk about that now. That's coming up next week and I will talk to you then.

## Kenexis Vertigo Software Overview

Now that you've heard some insights on technical safety, functional safety, and the IEC 61511 standard, let me tell you a little bit more about how to easily and effectively implement the safety life cycle using the Kenexis integrated safety suite and our SIS safety life cycle management tool, Vertigo. Vertigo is a comprehensive tool set for performing assessment calculations, documenting, and maintaining the design of safety instrumented systems.

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

Each safety function can then be analyzed by performing a SIL verification calculation, complete with a collection of tools for optimizing designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities. after the SIL verification calculations are defined, you can build an SRS by automatically generating a cause and effect diagram from the SIF definitions and other defined instruments.

Each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries. after the design phase, you can even use Vertigo to track and document testing throughout the entire life of the facility. Kenexis Vertigo is the most integrated, easy-to-use enterprise tool for allowing the development of SIS design basis information more efficiently and effectively than any other software application.