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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E20 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 20: IEC 61511, Clauses 9.2.5 to 9.2.9 (SIL 4 Warnings, SIL Stacking, and Allocation Documentation)

—

## Introduction, Disclaimer, and Episode Overview

If you did your risk analysis and came up with the need for SIL-4, that's not good. You should probably start over. Welcome to the Kenexis Functional Safety Podcast. I'm your host, Ed Marszal, and I'm the 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. Okay.

So, we are still in the allocation section of the standard. We're looking at Clause 9, Allocation of Safety Functions to Protection Layers. Last week, we looked at the beginning of allocation, what the purpose is, what we're trying to accomplish, and then we went in all the way through Clause 9.2.4 that talked about the safety integrity levels.

That would be safety integrity level 1, 2, 3, and 4. I also noted that while the current version of IEC 61511 and IEC 61508 list out a safety integrity level 4, the original ISA 84 that was released in 1996 did not acknowledge safety integrity level 4. And basically, the rationale that we had when we released that was that it's so difficult to achieve SIL 4 that you're probably not going to be able to do it right out of the gate. Beyond that, even if you can, do you really want to? So, there's a lot of concern in industry about putting so many eggs into one basket.

I mean, that is a very high level of risk reduction that you're trying to get out of one system where any failure in that analysis or any failure in the implementation of that safety instrumented system is going to be potentially catastrophic.

So, we are believers in defense in depth. Don't put all of your eggs into one basket. Don't rely on one protection layer, one system to keep you safe. Spread that risk around to multiple independent protection layers if at all possible.

So, that's kind of the desire. And the IEC 61511 standard starting all the way back in 2003 acknowledged SIL 4. 1998 is when the IEC 61508 standard acknowledged SIL 4. So, it is something that we have. It's something that's acknowledged. It's something that occasionally is implemented.

But at the same time, you have to be very careful about what you're doing in SIL 4. And while the Clause 9.2.4 talks about the SIL 4, acknowledges SIL 4, shows you the SIL 4 categories and ranges, it also steps back from that a little bit and provides a lot of admonishments, a lot of additional requirements, a lot of things to think about, a lot of considerations, so that you don't just run blindly into SIL 4 territory.

## SIL 4 Standard History and Today's Agenda

As a matter of fact, there are three sub-clauses in Clause 9 that warn you away from using SIL 4. And those are the ones that we're going to cover today.

So, kind of the big topic for today is going to be what happens when you get to SIL 4, why you probably don't want to use SIL 4. And if you do get in the situation where your system is telling you that you need SIL 4, ways that you might want to back out of it, go around it, get away from it, look at different options.

And those are going to be clauses 9.2.5, 9.2.6, and 9.2.7.

In terms of clauses, these clauses are extremely wordy, which is kind of a departure for the Standards Committee, how they do their writing. But it is what it is. So let's go ahead and dive into all of the restrictions.

I wouldn't exactly say restrictions. Maybe considerations, concerns, things to think about before you go down the road of implementing a SIL 4. Okay. Let's dig in.

## Clause 9.2.5: Reconsideration Requirement at SIL 4

So, clause 9.2.5 is the first admonishment.

And it says, and again, I'm going to do some reading because some of these clauses, again, are very long and wordy. So let's go and see what it says first. Okay. 9.2.5. In cases where the allocation process results in a risk reduction requirement of greater than 10,000 or average frequency of dangerous failures of less than 10 to the minus 8 per hour for a single SIS or multiple SIS in conjunction with a BPCS protection layer, there shall be a reconsideration of the application. Okay.

This one is loaded. There's a lot to unpack here, a lot to think about here. Let's, and we're not done. We're not anywhere near done with this clause. Um, so let's, let's, let's delve into this.

So basically it's saying if you're greater than a risk reduction factor of 10,000 or your dangerous failure rate for a continuous mode or a high demand mode safety instrumented function needs to be less than 10 to the minus 8 per hour. If you go back up in the clause 9.2.4, this means that you have selected something that is in the SIL 4 or technically the SIL 4 or greater range. It says, if that happens to you, you must, there shall be, you must reconsider the application. And then it goes on to say EG.

So for example, the process, other protection layers. So it's kind of leaving a broad brush on what that reconsideration means. So what are all the different things that you need to consider what you should do? But basically it's telling you no good. Uh, start over. Uh, we can't deal with this. This, this is not good. This is not acceptable. We, we need, we need to do something. Okay. Okay.

Now, um, I'm going to come back to this, uh, toward the end of the section because it says, if you're at SIL 4 for a single SIF or multiple SIS or single SIS, multiple SIS or SIS in conjunction with BPCS protection layers. So this analysis and reconsideration should extend to, according to the standard, and this is a highly debatable topic, a lot of, a lot of things to think about, but this could extend to any combination of instrumentation and control based risk reduction.

So if I've got one BPCS credit, one alarm credit, and a SIL 2 safety instrumented system, guess what? That is four orders of magnitude of risk reduction. That's a risk reduction factor greater than, well, technically right there, it was equal to, uh, 10,000. So, it's a pretty broad analysis that says we don't want to over consider the effectiveness of instrumentation and control.

And that's not just one system, but all of the different protection layers, uh, that are, that are capable of, uh, providing risk reduction or are credited with providing risk reduction, uh, in your safety instrumented function. So, uh, pretty high bar there.

Uh, so, SIL 4 in any combination of four orders of magnitude of risk reduction with an instrumented system. Now, most of the time, you're not going to cross this threshold because even if you have two BPCS protection layers and a SIL 2, that'll get you to equal the 10,000. Um, you might need to exceed the 10,000 before you kind of cross into that threshold. Uh, but again, uh, at a minimum, you need to do some thinking to make sure that this is what you, what you want to do, what you need to do.

Okay, so it says you need to do a reconsideration. Uh, what is that reconsideration? What does it involve? What do you need to think about? What do you need to do? Um, so you need to do a reconsideration. Let me get back to the text. So reconsideration of the application to determine if any risk parameters can be modified so that the risk reduction of greater than 10,000 or average of frequency of dangerous failure of less than 10 to the minus 8 per hour is avoided.

## Clause 9.2.5 Bullet Points: Inherent Safety Measures

So basically, can we do a different kind of allocation? Can we allocate to, uh, a non-instrumented safeguards? Can we redesign the process so that the risk is lower? So I want to do some sort of risk reduction if it's feasible in a way that does not include, uh, a safety instrumented function.

Okay, so that's, uh, most of the clause. Then we're going to delve into the world of, uh, or delve down into the bullet points. And, and this clause has four bullet points and a note. So let's, let's dig into it.

It says the review shall consider whether, and then the four bullet points. So the review shall consider whether the process or vessels and pipe work can be modified to remove or reduce, uh, hazards at the source. So reanalyze your process. Can you make it inherently safer? Lower temperatures, lower pressures, less toxic material. Is there some way to bring that consequence down? Okay. That's item number one.

Item number two. The review shall consider whether additional safety related systems or other risk reduction means not based on instrumentation can be introduced. So with bullet point number two, uh, we said, okay, can we make it inherently safer? If we can't make it inherently safer, can we put some other administrative controls or some other non-instrumented, mechanisms in to reduce risk as independent protection layers?

We are trying to reduce our, uh, risk using, uh, not only multiple independent protection layers, but let's see how much diversity we can get into those protection layers and not rely on instrumentation if that is possible. Okay. Okay.

The third bullet point, uh, the review shall consider whether the severity of the consequence can be reduced, e.g. reducing the amount of hazardous material. So I kind of already went here. There are two kind of inherently safer bullet points here, uh, with one of those bullet points, uh, being a, you know, modifying the process vessels pipework. And then the third bullet point, uh, coming in and seeing if we can do a reduction mechanism, uh, in the quantities of material, uh, to reduce the severity of consequence as part of that, um, uh, inherently safer review.

The fourth bullet point, the review shall consider whether the likelihood of the specified consequence can be reduced, reducing the likelihood of the initiating source of the hazardous event. So look at all of those initiating events and tell me whether or not we can reduce the frequency of those initiating events. Again, plant redesign, different mechanisms of control. Is there some other way that we can, um, you know, make that frequency smaller?

So, uh, you know, there was a lot to that. Um, and, uh, ultimately what, what we're, what we're looking at with all of those things is, you know, the, the, the, the mechanism to reduce the risk right out of the gate without, uh, relying on that, um, um, you know, reduce the risk without, without relying on instrumented systems. Because in general, uh, you know, as everyone has mentioned, there is a pretty, you know, large over-reliance on, um, instrumented systems. And that's what we're trying to avoid.

So four orders of magnitude, so SIL 4 or four orders of magnitude of any type of instrumentation, we are required to reassess the process and, uh, make sure that the risk is what we think it is. And look for any ways that we have at our disposal to reduce the risk without implementing that four orders of magnitude of risk reduction or that SIL 4 coming out of the safety instrumented system. Okay. So, uh, we have that as 9.2.5. That's the end of 9.2.5.

## Clause 9.2.5 Note: Human Factors and Systematic Failures

But there is still a note. So let me go ahead and read through the note. Even the notes in this one, uh, end up being very long. So, all right. Note. Applications which require the use of a single SIF with a risk reduction requirement of greater than 10,000 or average frequency of dangerous failure less than 10 to the minus 8 per hour need to be avoided. Because of the difficulty in achieving and maintaining such high levels of performance throughout the SIS safety life cycle.

Risk reduction requirement greater than 10,000 or average frequency of dangerous failure less than 10 to the minus 8 per hour can require high levels of competence and high levels of coverage for all factory acceptance testing, proof testing, verification, and validation activities.

So, one of the things that's interesting to note here is that they're discouraging you, strongly discouraging you, from going into SIL 4 or 4 orders of magnitude of risk reduction. And they say that it's hard to get there because, you know, the maintenance and the design to get to that is extremely difficult.

So, it's going to be extremely difficult to get to that level. But beyond the random hardware failures here, we're also talking about errors that could occur that are systematic, human failures that could occur during the design and the engineering of this process. So, your FATs, your proof testing, your verification activities, your validation activities, all of those items are things that, you know, need to be considered. And they don't, you know, necessarily result in or relate to the random hardware failures that are going to be in the SIL verification.

So, you know, SIL verification. It's hard to run a SIL verification and verify that you've achieved your SIL target for SIL 4. But even beyond that, just looking at human factors, some have argued that you can't even get to SIL 2 when you're considering human factors. So, that's kind of a big item that people need to think about when you're doing your design.

So, admonishment number 1, 9.2.5, basically says, you know, and I've talked about it for a long time now, but if you hit SIL 4, redesign your process, make it inherently safer, redistribute your safeguards, redo your allocation, so that your allocation doesn't include all of these instrumented safeguards.

## Clause 9.2.6: Protection Layer Independence at SIL 4

Okay, moving on to admonishment number 2, which is clause 9.2.6. Let me go ahead and read. And this one, again, is going to have a lot of bullet points, and the bullet points have a lot of notes. So, bear with me for a second as I kind of clamber through this one.

Okay, 9.2.6. If after further consideration of the application and confirmation that the risk reduction requirement is greater than 10,000, or average frequency of dangerous failure is less than 10 to the minus 8 per hour, if that is still required.

So, basically, 9.2.6 starts where 9.2.5 left off, saying, okay, I want you to redesign the process and redesign your safeguards to not get to SIL 4. But if you still get there, now it's the rest of the clause. Then, consideration should be given to achieving the safety integrity level requirement using a number of protection layers with lower risk reduction requirements.

If the risk reduction is allocated to multiple protection layers, then such protection layers shall be independent from each other, or the lack of independence shall be assessed and shown to be sufficiently low compared to other risk reduction requirements.

So, basically, if you absolutely unequivocally need SIL 4, there is no way around it. You have to get to SIL 4. Then, don't do it with one safety instrumented function. Split it up into pieces. See what you can do to go multiple independent protection layers instead of relying on one function that is going to be able to achieve that risk reduction requirement.

All right.

Now, there are three bullet points coming up. So, the following factors shall be considered during this assessment. And it gives three factors. Each of these factors has bullet points or notes associated with it. So, let's go ahead and clamber through this.

## Clause 9.2.6 Common Cause Assessment Factors

Bullet point number one. The first factor to consider is the common cause of failure of SIS and the cause of the demand. So, if you're in this SIL 4 situation, explicitly, deliberately look at the relationship between the safety instrumented function and the causes of demand to make sure that they are as independent as possible. And this might require you digging into some fault tree analysis to make sure that any relationship between them is going to be tolerable.

Now, there are a couple notes to this. The note, note one and note two. So, note one says, the extent of the common cause can be assessed by considering the diversity of all devices where failure could cause a demand and all devices of the BPCS protection layer and or the SIS used for risk reduction. So, consider all of the diversity, all the devices between the demand and the BPCS. Make sure that things are separated out.

Note two. An example of common cause between the SIS and the cause of demand is if loss of process control through sensor fault or failure can cause a demand and the sensor is used for control is of the same type as the sensor used for the SIS. So, not the same specific sensor, but even the same type is going to result in some common cause failure functionality that you're going to need to consider. Okay. So, look at common cause between the SIS and the cause of demand.

Next bullet item. The factor that needs to be considered during the assessment is common cause of failure with other protection layers. So, bullet one said, don't, you know, assess common cause between the initiating event and the SIS you're trying to create. Now, it's saying consider common cause between the SIS and the other protection layers. So, notes there.

Note three. The extent of the common cause can be assessed by considering the diversity of all the devices of the BPCS protection layer and the SIS used. So, look at the degree of diversity, the equipment that you're using. It's critical. Note four. An example of common cause between SISs providing risk reduction is when two separate and independent SISs with diverse measurements, diverse logic solvers, are used, but the final actuation devices are two shutoff valves of similar type or a single shutoff valve that's going to be activated by both of those functions.

So, fully, physically, and functionally independent is what we're shooting for between our protection layers. All right.

Finally, last item. The third bullet point. The assessment needs to consider any dependencies that may be introduced by common operations, maintenance, inspection, or test activities, or by common proof test procedures. So, now we're looking at commonality not just in the design, but commonality in how you're maintaining and testing the equipment.

So, that's kind of not going to show up necessarily in your SIL verification or your risk analysis. That's more those human factors between numbers. Okay. So, there are a couple notes here.

Note five and six. Note five states, Even if the protective layers are diverse, then synchronous proof testing, meaning you're testing all those devices at the same time, will reduce the overall risk reduction achieved. And this can be a significant factor in impeding achievement of the necessary risk reduction for the hazardous event. If you bypassed all your transmitters for testing and left all your transmitters in bypass, well, that's kind of, you know, that's a failure we need to consider in this process.

Okay. Note six. When high levels of risk reduction are required and proof tests are desynchronized, according to note five, then the dominant factor is normally common cause failure, even if multiple independent protection layers are used to reduce risk. Dependency within and between protection layers providing risk reduction for the same hazardous event can be assessed and shown to be sufficiently low. Okay.

So, 926 basically says if you end up at SIL 4, your calculations, your SIL verification might say that this is okay, but it might not be okay when you consider human factors. Okay.

This is something that we, the human factors, I already talked about this. We've talked about this many times. We're going all the way back to clause five, competency, verification, validation. All of these things are important when you're designing your safety instrumented system. And a lot of those things that are important in your safety instrumented system didn't really come into play when you were doing your SIL verification. So, there are other aspects of the standard that you need to consider when you're doing your design process.

And chapter five, section five, clause five, talking about management systems, verification, validation, all of that is things that need to be considered in your overall life cycle management, even if they don't show up in the SIL verification. Okay. So, let's go ahead and move on.

## Clause 9.2.7: Quantitative Risk Analysis for SIL 4

We have the last clause of three. So, I said that there were three clauses that are the, if you got to SIL 4, you probably screwed something up and you need to re-look at what you're doing.

So, the last one is 9.2.7. 9.2.7 states, if a risk reduction requirement greater than 10,000 or average frequency of dangerous failure less than 10 to the minus 8 per hour is to be implemented, i.e. SIL 4. Whether allocated to a single SIS or multiple SIS or SIS in conjunction with the BPCS protection layer. So, all of the instrumentation and control protection layers put together. Okay.

So, if you're trying to achieve four orders of magnitude of risk reduction with instrumentation, then further risk assessment shall be carried out using a quantitative methodology to confirm that the safety integrity requirements are achieved. This methodology shall take into consideration dependency and common cause failures between the SIS and three bullet items.

So, before I get to these bullet items, we at Kenexis do this a lot. We have an incredible degree of expertise in this process. And it is something that we refer to as focused QRA, focused quantitative risk analysis. So, it is a quantitative risk analysis, but it's not a general purpose risk analysis that looks at a, you know, a whole wide, wild collection of factors. It is a process that is going to look at one scenario at a time. And that risk analysis process is going to include things like the fault tree analysis for better consideration of commonality.

It's going to include event tree analysis, quantitative bow tie, explosion modeling, dispersion modeling. So, sharpen the pencil and make sure that that risk reduction is what you really need.

So, you know, looking at that, what the clause says, it's not cheating, if you will, to do a more detailed risk analysis. You know, some people kind of derogatively refer to it as pencil whipping as, you know, a way to just kind of, you know, write some numbers down and make your SIL target go away. That is not what we're talking about here.

We are talking about a rigorous risk analysis that needs to be performed, very defensible, done by experts, whether that's in your organization or, you know, outside with an external consultant.

So, not only does the standard allow you to do that kind of analysis, it basically is requiring you to do that kind of analysis. They really want you to make sure that if you're in that SIL 4 territory, don't just blindly implement it. Do some risk analysis to make sure that you're there.

Okay, so that more detailed risk analysis that you need, there are three bullet points for things that it needs to consider.

Number one, any other protection layer whose failure would place a demand on the safety instrumented system. There, we're looking at that commonality aspect. Okay, so that's one of those things where you're going to need fault tree analysis that is able to elegantly handle commonality between protection layers and between protection layers and initiating events.

The second item is any other SIS reducing the likelihood of the hazardous event. Again, we're worried about a commonality issue. If you have two safety instrumented functions, is there some degree of commonality that we're going to need to address using fault tree analysis that is going to possibly prevent us from achieving our tolerable levels of risk and ultimately requiring us to perform a different, better design.

And then the third and last item is that you need to consider any other risk reduction means that reduce likelihood of the initiating event, such as safety alarms. So, you know, looking at this list of things, basically 927 is the clause that says do a more detailed risk analysis and make sure that's what your risk reduction requirements are.

## Summary of SIL 4 Admonishments in Clauses 9.2.5 to 9.2.7

So, if I could sum up, go back, look at these requirements. You know, let's look at them again.

So, 925 says if you hit SIL 4, redesign your process, make it inherently safer.

926 says if you can't redesign your process and make it inherently safer while you're doing your design, be very careful and cognizant of common cause, both from a PFD perspective and also a systematic human failure perspective.

927 says, okay, if you think you need SIL 4, please do a deeper dive into your risk analysis and confirm beyond the shadow of a doubt that you actually need that high level of risk.

So, pull out the big guns, sharpen the pencil, do that detailed quantitative risk analysis to make sure that you need SIL 4. Okay, so those are the warnings about SIL 4.

Let me do a couple more quick items that are going to close out Clause 9.2, which is going to allow us next week to get into Clause 9.3, which is a beast, because we talk about the basic process control system as a protection layer.

> *[Break: approximately 36:47]*

## Clause 9.2.8: SIL Stacking and Combined Function Analysis

is there are people who say, who think that SIL 1 plus SIL 1 plus SIL 1 is SIL 3, but it's not, or it's probably not. There's a chance that it's not. What do we mean? What are we getting at here? So let's say I have three pressure transmitters and three valves, and they're all connected to the same SIS logic solver. I can't say that transmitter A is SIL 1, transmitter B is SIL 1, transmitter C is SIL 1. Therefore, I've achieved a total risk reduction of three and I'm good to go.

Your logic solver is a common point of failure that can easily constrain the ability of the overall system from achieving three orders of magnitude of risk reduction, especially if you did something like, uh, use a SIL 1 rated or a general purpose PLC to get to that SIL 1 level. So it's saying, if I've got three functions that need to achieve a total of SIL 3, you don't have three separate functions.

You need to combine those three functions into one and make sure that you're able to achieve that overall three orders of magnitude of risk reduction, considering the combined system, SIL 1, instead of trying to look at them one at a time. So SIL 1 plus SIL 1 plus SIL 1 will not necessarily get you to SIL 3. And you need to think about the fact that it is a SIL 3 and achieve a SIL 3 in your calculations and your analysis.

## Clause 9.2.9: Documenting Allocation Results

And the last clause of 9.2.9 states, the results of the allocation process shall be recorded so that the SIFs are described in terms of the functional needs of the process. For example, the actions to be taken, set points, reaction times, activation delays, fault treatment, valve closure requirements, and in terms of risk reduction requirements. So here we're kind of crossing the threshold a little bit, if you will, between the allocation and safety requirement specifications.

But ultimately what we're saying is during the allocation process, there is a lot of information that needs to be developed that we're going to carry through to future life cycle activities.

And while you have your HAZOP team together, you would probably want to get these things documented to make life easier as you go further on down the road.

Okay, so that's the requirement. This requirement does have a big note in it. Note, note, just one note on clause 9.2.9. The note states the following, this description can be in an unambiguous logical reform and can be referred to as the process requirement specification or the safety description. So they're kind of drawing a line saying, well, we don't exactly mean the SRS, but you know, it contains a lot of the same information. Okay, continuing on in the note, the description can make the intent and the approach used in the allocation process clear.

The process requirement specification is used as input information for the SIS covered in clause 10 and can be sufficiently detailed to ensure adequate specification of the SIS and its devices.

For example, the description can include the set points for sensors, the process safety time available for response and the valve closure requirements.

So if you look at a Kenexis open PHA file, you'll see that we have locations, we have fields to be able to document a lot of this information, especially if this information needs to be collected while you're doing your PHA study, while you have the process, the full team of people in the room, because by the time you get into the SIL verification or, you know, the SRS phase, it might be difficult for your instrumentation and control engineers to be able to develop this information.

So uh, for uh, sanity purposes, uh, the information that's going to need to be developed, uh, in that SRS, you might want to take a first pass at it, uh, while you're still in the HAZOP LOPA study.

Okay. So that is clause 9.2.9. We are still in allocation. There's still a lot to talk about in allocation, but we have come to the end of this week's edition. Next week, we're going to go and we're going to hit clause 9.3. It is one of the clauses that has probably the most confusion, the most, uh, questions, concerns, comments, people doing things wrong, arguments, debates. How do we handle that basic process control system? So that's coming up in the next clause.

And, uh, I mean, there's clauses 9.3.1 through 9.3.5. We might not even get all the way through those because there's so much to talk about in this section, looking forward to talking about it. And I will catch you next time.

## Closing Remarks and 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.

> *

*